Preface: There has been a lot of talk lately about whether or not Test First is Dead.This is a complicated and tangled issue, so I want to simplify many aspects of this debate in this blog post to focus on a single aspect of TDD:
Test Run Time.
So for this blog, let's ignore the distinction between unit, integration, acceptance tests, even manual tests. I'll lump them all together into a single box - 'tests' so we can focus on the 2nd benefit of Tests: Feedback
How fast is fast enough for you tests to run? There is a lot of discussion. minutes? seconds? fractions of a second?
Usually there is a very important step skipped in this discussion. People never seem to ask:
What does it matter how long they take?
Cycle Time
Have you ever needed to make 'just a small fix'? You change a line of code. Compile, save, deploy (maybe to your phone or websever) look at result.
"Damn." That didn't actually fix it. You change the line again, Compile, save, deploy, look at the result... "Damn".
4-5 tries later and it's fixed. less than 20 characters typed. Less than 60 seconds of work and yet the clock says it's an hour later than you started.
What is going on here?
Again a lean graph is helpful in mapping out and understanding this system.
The problem is for every 10 seconds of work you do, you have to wait 10 minutes to get your feedback. This is a highly infective way of working, which is why we don't do it that offend.
Although this phoneme is well know enough to inspire xkcd comics
To discuss this part it is better to use the repeat notation to display the above lean graph
Work to Wait Ratio
Now, we tend to want high feedback but we also want a good work to wait ratio. I find that in practice we want at least a 3:1 work to wait ratio.
That means if it takes you 10 minutes to get feedback (test it out) then you will probably end up coding in 30 minute or longer chunks before running the code. If compiling and running takes you 3 minutes you'll work in at least 9 minute chunks.
This allows a lot of time for mistakes to fester and complexity to compound.
A lot of good Test Driven Developers I know like to run their test's at least 3 times a minute. That means 20 seconds per cycle, which means an absolute max of 5 seconds per run to achieve the minimum work to wait ratio.
But this changes it get to the 'very very quick' stage. If you are typing in word it underlines typpos as you go. This might seem like a minor connivence over the 'Check Spelling' feature but, then again, when is the last time you remember running a spell check manually?
It worth noting I know many legacy systems where the compile time alone can take 3 hours. That means if I come back from lunch and program for 1 hour, I will not be able to see the effects of my changes before I go home for the night.
Discovery
One last thing to consider is the aspect of discovery when creating. When you are trying to be creative and discover 'the right thing' then the immediacy of feedback is very very important. This is why many people find themselves preferring things like paper, whiteboards, wysiwyg editors when they are brainstorming.
This is part of why you are seeing more things like continuous test runners and website monitors that automatically refresh on file change.
You'll find that the longer the cycle times the more deliberate each action becomes. This drastically lowers the chance for a joyful discovery. Not many people played around with punchcards.
If you are interested in this aspect of feedback, I suggest you check out this talk [inventing on a principle] by Bret Victor. Who has though about this more than anyone else I know of.
No comments:
Post a Comment