One of the biggest challenges for someone experiencing TDD the first time is working in the small steps. The small steps of TDD appear to be an independent discovery of John Gall’s observation described in the Systems Bible:
As Kent Beck told me years ago, after the first test passes, you’re in maintenance. From that moment on we’re evolving the behavior of the product, while keeping all previously working behaviors working.
John Gall also weighs in on designing a complex system from scratch.
When I first read that statement, I thought, what is he talking about? My team was successful a few times with waterfall. We got the system to work, eventually. But how did we do it? Over the years of doing TDD, I realize Mr Gall is correct. We went back to small steps; the small steps of debugging.
When push comes to shove, people chasing bugs are perfectly comfortable with small steps. We’ll ask ourselves what does this line of code do? Maybe we log intermediate results; soon the debug code outweighs the production code. Sometimes we’d get out the debugger and single step. Some even write a test program that tries out the scenarios. In all these cases where do we start? We starting from a simple case and build confidence one small step at a time.
If you were building a circular buffer object and it did not work, you’s start with the basics. Is the FIFO empty upon creation? If you put something in, is it no longer empty. Can I get out the thing I put in? Is it empty once I do?
The person doing debug later programming knows the small steps once they are forced into them due to the reality of defects in their work.
So people struggling with the small steps of TDD, maybe you’ll be better off doin them proactively to prevent defects rather than reactively in response to defects. You already know small steps.