What I learned from Kent Beck

This is a summary of what learned from a “Mastering TDD” course with Kent Beck. Given he is the creator of JUnit, I guess his thoughts on unit testing are worth considering. :-)

In some cases I might have rewritten, changed, extended or simply misunderstood what he was saying, but these were my notes from the course, nevertheless.

  • Doing TDD is like losing weight. You like having lost some weight, but not actually losing it.
  • Taking really, really small TDD steps is useful when you’re unsure/confused about the code you are writing. That way you are at least moving forward.
  • What kills productivity isn’t doing something slowly, but not doing it. I.e. when you switch to reading email, surfing the web, etc instead of working.
  • Implementing a piece of code inside a test keeps your options open if you’re not sure about the future interface.
  • Start writing the test which you expect to learn the most from.
  • Most important, according to Kent: Writing a test is really telling a story about the code. Having that mindset helps you work out many other problems with testing.
  • Deleting tests comes down to story telling – which tests do we need to tell the story about this code. (There is also a technical/coverage aspect, but it is of lower importance).
  • When unsure about whether to clean something up or not – think about the amount of leverage it will give you. Worth it?
  • When coding exploratory (without TDD), start TDD:ing when/if you don’t expect the code to die anymore, or when you think you’ve learned the most important lessons.
  • In many cases: The more discussion, the less important the decision. Everyone agrees about the really important ones.
  • Write code in a functional style, as it is more suitable for testing.
  • Consider not using dependency injection as it makes TDD harder by encouraging a design where dependencies are spread out over the system. Instead, design many stand-alone modules which are unit tested individually without the need for mocked dependencies, then join them together in other classes which are tested through integration tests.
  • Avoid abstact superclasses for unit test classes as they make the individual test classes harder to read.
  • Duplication is often more okay in tests than in the production code because readability of tests is so important.
  • For infrastructure-related setup code, @Rule can be used instead of inheritance in many cases.
  • Write tests on the high and low level, but be weary of too many tests on the mid level. They tend to be more of a problem than help when refactoring.
  • Kent: “I try not to have more tests than I need”
  • Use one test class per fixture (i.e. set of test data). Name the classes after the fixture. That is how JUnit is designed and intended to be used.

2 Responses

  1. Love this one: “Consider not using dependency injection as it makes TDD harder by encouraging a design where dependencies are spread out over the system. Instead, design many stand-alone modules which are unit tested individually without the need for mocked dependencies, then join them together in other classes which are tested through integration tests.”

    Peter Liljenberg - September 9th, 2011 at 07:49
  2. It wasn’t equally well received by everyone back at work when I talked about it during lunch. :-)

    Someone mentioned something along the lines of “been away from reality for too long”. :-P

    Henrik Jernevad - September 9th, 2011 at 08:31