Attend “Make Your Code More Testable” if You Get a Chance

Last week I attended the “Make Your Code More Testable” workshop by Ted M. Young (@jitterted). I was not sure if I wanted to attend yet another workshop this year as I saw the first tweet about this workshop. After I saw the recommendations by Gitte Klitgaard, Esther Derby, Kent Beck and GeePaw Hill I changed my mind, and I am happy I did.

The workshop was split in 4 parts each 3.5 hours long. The first 3 days we focused on refactoring and used testing to make sure we did not break things, while on the last day we shifted the focus to testing and used refactoring to improve our tests.

I found this approach a lot better than the “traditional” way where you start with tests and then use refactoring more of an afterthought. Ted’s approach with cleaning up code first is far better suited for your production code – then that code is seldom well-structured. One of many heuristics we learned can help us as an overall goal for refactoring:

Reduce Time To Understand

 

4 modes of refactoring

The big point for me of day one was the idea of the 4 modes of refactoring. In each mode we focus on a particular goal and therefore use different refactorings and approaches:

• Clarify – tiny refactorings for clarifying code
• Clean – tidying code up to improve the design
• Prepare – clear the way for new functionality
• Apply learning – putting newly gained knowledge into the code

 

Primitive obsession

The big topic of day 2 and 3 was primitive obsession. That describes the problem of using primitive data types to represent domain ideas. While we may store a customer Id as an integer in a database, we should not use the type int throughout our code to represent the customer Id. This leads to the annoying method signatures like

method(int, int, int, bool, bool, string, string, string)

where we have no clue if we put the right int in the right place.

The big Aha! moment for me was in the exercises where we made significant refactorings but only for a minute or two had tests that did not pass (always green refactoring). Making changes this way is stress-free, because everything is working all the time and you can focus on the next step. It is in a way similar to the Mikado Method, even if it uses a totally different approach.

 

ZOMBIES and DAMP

The ZOMBIES acronym is a good way to remember all the basic scenarios you should test:

• Zero (or empty)
• One
• Many (or More)
• Boundary Behaviours
• Interface definition
• Exceptional behaviour
• Simple Scenarios, Simple Solutions

In combination with DAMP (Descriptive And Meaningful Phrases) we not only cover a good range of test cases, but we make sure that they are understandable and with that maintainable.

 

Conclusion

This was the best workshop on refactoring I ever attended and even with all my knowledge about this topic I learned a lot. I strongly advise you to attend this workshop when you get a chance to do so.