TDD By Example: Chapter 1 Multi-Currency Money

Summary

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 describes that he is going to put everything he needs to do on a list. He is going to focus on one thing at a time. He will add things to the list as they come up.

We start to understand one of the main tactics of TDD.

When we write a test, we imagine the perfect interface for our operation.

He writes the test so that code has the API he wants it to have. He then gets the test to green as fast as he can. 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:

1. Add a little test.
   1. Run all tests and fail.
   2. Make a little change.
   3. Run the tests and succeed.
   4. Refactor to remove duplication.

There is a sidebar on "Dependency and Duplication". He mentions that dependencies are the key problem in software at all scales and that the key to removing dependencies is 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.

Commentary

I think the sidebar on dependency and duplication is the most interesting thing in the chapter. When he writes:

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, like building trust on a team.

The rest of the chapter is a 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 possible.