Author: Kent Beck
Buy: Book Depository
There is a very common argument against writing tests which sounds like "writing code with tests first is much slower than just writing the working code". One of the key takeaways of the book for me was that this is not true. Try developing the same feature again and again, once with TDD and once without and measure the time. There is not a big difference, and once you are getting better with TDD, it can even be faster. Why? Because sometimes you don't even realise how much time you actually spend debugging your code and making it work. If write your tests first this the iteration and revealing of bugs goes much faster.
And then we didn't even talk about the time that you gain in the future when your introduced changes are guarded by tests, or the benefit of the cleaner API that emerges from top-down design of your code.
The loop of TDD
- Write a test that fails
- Make only as much production code that makes that single test pass.
- Refactor
Do the simplest thing that could possibly work.
I'm not a great programmer. I'm just a good programmer with great habits.
More time at the desk does not equal increased productivity for creative work.
The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills.
The majority of the cost of software is incurred after the software has been first deployed. Thinking about my experience of modifying code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore, I should make it easy to read.
Trust energizes participants. We feel good when things work smoothly. We need to be safe to experiment and make mistakes. We need testing to bring accountability to our experimentation so that we can be sure we are doing no harm.