Refactoring TDD habits
It’s about 15:21 on 19th September, a group of us from the London Software Craftsmanship Community gathered to leave for SoCrates UK 2013. We all gathered in the same and luckily found empty seats next to each other.
Amongst a lot of jokes, we suggested lets do a small dojo in the two hours we will be travelling. Wifi is free but terrible, on this train – nevertheless we tethered our phones and enabled Wifi on our laptops to make the most of the bandwidth.
This was also about the time when others sitting around me took notice of the desktop wallpaper, it looked something like this:
One thing lead to another, and before we knew, we were going through the above list of habits – some found the habits difficult to remember, others found duplicates and overlaps. There was this tendency that, this is a big list to remember when doing TDD!
So like developers we said we can “refactor” these habits into something more meaningful, maybe even organise them as per our thinking process.
From this conversation the below list was born:
12 habits to good TDD programming:
1) Write the assertion first and work backwards
2) Test should test one thing only
3) See the test fail
4) Write the simplest code to pass the test
5) Refactor to remove duplications
6) Don’t refactor with failing test(s)
7) Write meaningful tests
9) Keep your test and model code separate (except when practising TDD-as-if-you-meant-it)
10) Isolate your tests
11) Organise your tests to reflect model code
12) Maintain your tests
You can notice already that the 13…habits shrunk to 12 habits, and their order changed in comparison to the original.
Then @Frankie mentions the difference between Test-first development and Test driven development, no one claimed to know it, but suggested the below:
– you start the development with tests, and change the tests if goal is not achieved via model (domain) code. – No guidelines about design, flexible approach.
Test driven development
– test drives the model code, you never change the test, only model code to reflect any changes that does not satisfy the tests! Guided by design.
Model code = production code or implementation, domain (better term)
Soon we arrived at Moreton-in-Marsh and our focussed changed to getting a taxi to the venue.
I continued contemplating with the idea of collaborating with other developers and ironing our this list – so it can be helpful at the least.
I met @gonsalo and @sandromancuso and ran the idea by them and they thought it was certainly an idea to present and get others involved to see what the final outcome could be.
Next morning everyone was proposing their presentations at the “Open Session”, and I took the chance of presenting – Refactoring TDD habits… in the Cheltham Loft room in the house called Coach at the Cotwold estate!
30 minutes into the conversation and we already attracted discussions between @sleepyfox and @sandromancuso, we did try to persuade them to avoid tangenting from our core topic of discussion.
@sandromancuso also shared with us one of the rules of simple design – as these have evolved over time, these sorta look like this on the flip chart he scribbled on:
– passes all tests
– minimises duplication
– maximises clarity (clear, expressive, consistent)
– has fewer elements
The idea is that all your actions and practises could use these as guiding light to keep on track.
An hour and few minutes later and we have refactored and cleansed the original 13 habits down to 12 habits – reshuffled and rejuvenated. They may not be perfect but close (Kent Beck: use ‘perfect’ as a verb, not a noun – its a journey not a destination!
I sincerely hope that these list of habits do cover the essence of the principles, values and practises of TDD programming.
Prepare yourself with things you should or should not do, and then perform the Red-Green-Refactor actions to satisfy the TDD process.
The things some of the attendees not like is the way of the first list of habits were worded:
- definition of the word ‘model’ or ‘domain’
- use of the term duplication
- the habits being assigned with numbers
- use of the term assert – one assert per test or groups of assert per logical test
I also brought up the topic of the difference between Test-first development and Test driven development – and there were disagreements about it amongst the attendees, on the meanings of the definition itself. Please share with me your input!
Back to the final list of habits, @CarlosBle brought up a very valid point that some of the habits on the list might be time-based rather than relevant all the time – they were not linear but appear and disappear from the list depending on the current task in hand. We agreed we would sit together and work it out, but @sleepyfox was ahead of us and kindly drew this flow / state diagram on the flip chart that illustrated the list of habits but in a diagrammatic format:
@CarlosBle – please feel free to come up with your time-based / non-linear list and share it with us when you get a chance.
Although we got a lot out of the session with discussions on various topics, we haven’t covered everything and finished discussing everything!
I’m more of the idea, that we could try to look at the above habits as trigger points (practical and pragmatic use) to make us do the right things when we are writing code with the intention of writing good code…clean code…quality code…whatever the terminology be in your environment.
At the end of the day, good practises become habitual only when practised repeatedly, with focus and intent.
Please do provide constructive criticism, if any, such feedback to the above are very welcome as they help improve the quality of the post!
Thanks to @sandromancuso & @sleepfox for helping and participating during my session. Big thanks to Socrates UK – its host, facilitators, organisors and sponsors for making this event happen!