I’m a big fan of TDD; I’ve loved it since the first moment I scratched the surface. It puts the software development process in a new light, like looking at your code from a whole new perspective. A perspective that is more similar to what you experience while learning a third party API, rather than developing a class bottom-up.
It is as if you are learning your own API (class) while you develop it. And you tweak it to be exactly what you want it to be while it is growing, changing signatures to methods, names, refactoring all along the way.
The end result is often surprisingly simple. What you need, and nothing else.
Anyway, there is an aspect to TDD that is not brought up that often IME. It is the following observation:
If a class is test-covered, you can do brutal optimizations as long as you like, experimenting away, without worrying about breaking the code.
This is similar to the argument about bug fixing test-covered code – you may refactor away to make the code read better, be more understandable, and feel quite certain you are not breaking anything. The difference is that optimization tend to obfuscate code, not make it more readable!
TDD is the optimizers dream!
Tags: programming, tdd, optimization
Besök bloggosfären!
OlofB[eta] 
As long as your test coverage is ”good” enough.
Osias;
Yes of course you’re right. But that is another topic 🙂
I thought about mentioning that, but then I thought ”Heck why must we be so catious about things we know work good?”.
Well, I was thinking about you breaking something, when optimizing, that is not covered by the tests. I’ll try to describe an example:
Your tests simulate when someone adds 1 item to his/her shopping cart, then simluate someone adding 2 itens, then 100, then simulate 4 concurrent users adding things to their shopping carts. And all is green.
So you optimize putting some hash tables somewhere. And all is still green, and now is faster.
But now if, lets say, 50 simultaneous users try to add 10+ itens, the system starts to be veeeeery slow, because of some reason. Maybe the hash tables, maybe other thing. That’s something was working before, but you didn’t test for it. I think that can happen even if all the code was 100% covered by tests.
So, I agree, the optimizers’ dream. But still…
Yes Osias, even if the code has 100% coverage, it is still not proven to be correct code.
Would you be better of optimizing code that did not have any tests?
Thing is – the fear you are concerned about is mostly just that – fear. In practice, this is not a big problem, if you know how to write tests.
Writing sane and useful tests is an art that has to be practiced a lot though. I’m still a beginner, but so far the problem you are mentioning is nothing I’m worried about.