The first part of this chapter Beck gathers requirements and starts to define the acceptance criteria. He doesn't call what he does by those names but when he writes:
What behavior will we need to produce the revised report? Put another way, what set of tests, when passed, will demonstrate the presence of code we are confident will compute the report correctly?
I think he is talking about putting the requirements for the code into the tests.
He then describes that he is going to put everything he needs to do on a todo list and how he is going to focus on one thing at a time and when things come up he will add them to the todo list.
After the todo list is made, he writes the firs test. Now we start to understand the details of his approach.
When we write a test, we imagine the perfect interface for our operation.
He explains that he writes the test so that the code has the API he wants it to have. He then proceeds to get the test to pass as fast as he can. This point of speed is emphasized in the chapter. One of the most important things in TDD is to get to a passing test as fast as possible.
You probably aren't going to like the solution, but the goal right now is not to get the perfect answer but to pass the test.
The TDD cycle is enumerated:
- Add a little test.
- Run all tests and fail.
- Make a little change.
- Run the tests and succeed.
- Refactor to remove duplication.
There is a sidebar on "Dependency and Duplication". The point is made that having the same code in more than one place is not a problem, the problem is that changing the code requires changing it every place it's written. The key to removing dependencies is to remove duplication.
There is now a refactoring where duplication is removed in very small steps.
Do these steps seem too small to you? Remember, TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps.
That ends the chapter.
Dependency is the key problem in software development at all scales.
my eyes stop.
I wonder if that's true. I think about on my own experience and I feel like there is some truth to it. But could it really be the "key" problem? And can the answer to the "key" problem be as simple finding duplication and removing it?
I have these questions in my mind as I read on. Some part of me feels like there is a lot truth to that statement. Some part of me feels that there are much more pressing problems. I can't quite name them right now but I feel like they are there.
The rest of the chapter is good introduction to the technique of TDD. Beck emphasizes small focused steps. I appreciate that approach more and more in my day to day work. I'm starting to feel that I actually move faster taking as small a step as necessary.