I’ve been watching and studying K. Beck’s video series on TDD this week. These screencasts are really good in my opinion, I am glad that Kent made them. I would like to see more of them.
According to Amazon, I bought Kent’s book on TDD in January 2008. At that time I was working on a kind of experimental project at the University of La Laguna so I had plenty of time to practice TDD all day long. The software had to work but there was no deadline, it was a kind of grant, perfect for me to learn and practice. And we delivered clean code that worked finally. Well, today for sure I wouldn’t like that code.
With Kent’s book and the help of the TDD mailing list (Yahoo), I embraced the technique soon and stuck with it since then. So my style is quite “classic”, although I believe I use more test doubles than Kent (looks like he doesn’t use doubles at all, but I’d like to see that). However as I’ve gained experience and learned from others and from my own mistakes, my style has been evolving over time. Moreover teaching TDD to lots of people during these years has have a huge positive impact on the way I test-drive my code.
But now watching Kent coding has been a bit surprising to me. Notes to myself about the episodes:
Episode 1:
Kent writes the first test from the outside-in, but makes it pass bottom-up. Using a single test as a means to constantly validate the code he is writing works. He moves code from the test to production and back to the test, always moving in safe steps. My surprise he is that all the triangulation is performed with a single test, an evolving end-to-end test. I think I’d probably have written several tests, leaving the first one red for a while (he does that in an upcoming episode). From this very first episode I can notice that Kent uses the tests to maximize feedback, focusing on getting things done. Very pragmatic, I like that.
Episode 2:
Kent uses the “fake it until you make it” trick, returning a hardcoded zero value, but then rather than writing another test to triangulate, he uses the same one to make the production code more generic. Again very pragmatic. I only use “fake it until you make it” when I don’t have a clear vision of how to make it pass. That keeps my flow and gives me some inspiration. So in this case I would just write something more than “return 0”.
The surprise in this episode is that Kent prefers to leave some duplication in the code in favor of symmetry. Duplication makes me feel unconfortable so I would rather remove it. Now I value symmetry a bit more, I got his point.
Episode 3:
Kent removes several tests. In order to split a problem into smaller pieces, he leaves a failing test and moves on to test-drive those small pieces (methods) that are needed. When the big method works and the big test passes, he realizes the small methods should be private and so changes their visibility. Then the small tests don’t even compile and Kent just deletes them. He calls these “scafolding tests”, needed to flow with safe small steps but not necessary in the end.
To me this is a bit surprising, it’s definitely not my style but I see the benefit – flow and fast feedback again. I rarely delete tests, only when they are proven redundant (and I loose the 10$ as Kent says). When I find myself testing a method that should be private I question my design. It usually tells me that the method probably belongs in a different object where it’s public. If writing a specification (what tests really are from my point of view) turns out to be difficult, that gives me a hint about my design. However it’s true that sometimes premature design decisions may get you stuck, loose the flow.
Episode 4:
I really like the idea of test-driving the same problem from scratch several times to find out which order is the best. Choosing the tests appropriately is very important for TDD to be productive. To success with triangulation the order in which we choose tests is fundamental. This exercise is excellent, I will practice it more often with code katas.
Some conclusions:
I can see that Kent uses the tests to progress with steady pace in safe small steps, maximizing fast feedback loops. I see that the primary focus of his tests is not on documenting the behavior of the system, Kent just wants to get code working soon. The names of the tests are readable and tell a story but I like them to be more expressive. Sometimes Kent reflects only the input in the name, whilst I prefer to describe the behavior. As an example I would type “it_is_not_possible_to_remove_a_null” whilst he typed “removeNull”. I continously refactor my tests to improve their names, making sure I could copy and paste those names (together with the class name), paste them into a text document and deliver it as human readable documentation source.
I tend to use tests more as specifications than tests so I probably spend more time thinking of the tests and ordering them for the sake of an effective flow aftewards. The truth is that sometimes it’s hard to approach the problem from the outside-in and the pragmatism demonstrated by Kent helps with that. I’ll take advantage of these lessons to keep on evolving my style
Thank you Kent Beck for your book and your videos!
And thanks to my friend @pasku1 because I believe he told me about these videos.