Mastering Tdd Chapter Notes

Every now and then I open up my battered copy of Kent Beck's Test-Driven Development By Example book. Every time I come away with a little bit of extra insight that I missed before.

This time, I'm going to start with the last chapter, called 'Mastering TDD'. I haven't read this chapter yet, so thought it would be fun to start at the end and work backwards this time around.

• When you're new to TDD, the smaller steps you take the better. As you get more and more comfortable with it, you can start to leave some of the smaller steps out and see how that feels. For the most part though, smaller steps are better, more of a safety net.
• The Refactoring Browser for Smalltalk is recommended as the best refactoring tool available. Knowing you're supported by a refactoring tool makes you more confident in your own refactoring, which can be an advantage.
• You should test conditionals, loops, operations and polymorphism, but only those that you write. A better approach given though, is to write tests until "your feer is transformed into boredom". The tests are feedback loops in place to help you get answers, rather than being answers themselves (I like that).
• Indicators of bad tests: Needing to create a bunch of objects just to write one assertion (split into smaller chunks), if the test suite takes too longe to run (heightening the chances they won't be run at all), Tests that break unexpectedly mean could mean that things are too tightly coupled.
• "Code for tomorrow, design for today" as opposed to "Code for today, design for tomorrow".
• Feature one implented, feature two added, the commonalities between the two features stay together, the differences go somewhere else, same thing again for feature three.
• When you get really good at TDD, you become able to catch most of your mistakes faster than other people obversing you write the code can catch you making them. Really like that too.
• Check out Testing Object Oriented Systems: Models, Patterns and Tools - suggested by Kent Beck as THE comprehensive reference on testing.
• Tests are a means to an end, where the end is code that we have great confidence in.
• "Never delete a test if it reduces your confidence in the behaviour of your system."
• "Get red/green/refactor going in your own practice, then spread the message".
• "My goal is to feel better about a project after a year than I did in the starry-eyed beginning.

I went down a rabbit hole about Visual Studio for Smalltalk and applied to be sent a download link to it, it contains the refactoring browser built in. On the C2 wiki, someone recommended Smalltalk: An Introduction to Application Development Using VisualWorks by Trevor Hopkins as a great starting point.