In the last email, I talked about the abject fear I felt trying Test Driven Development (TDD) as a neophyte in an organization well versed in it, and about how TDD didn’t make sense to me that it could be useful.
Imagine going from fear to that’s it?
TDD has three steps (Red, Green, Refactor) that are really six steps but we like things to appear simple so we don’t scare people off:
1. Write Test describing the smallest discrete piece of behavior you can
2. Write Code that fails that test (RED)
3. Run the test, find out it fails (hopefully for the reason you think it will fail!)
4. Write the simplest code you can to pass the test for its failure reason
5. Run the test again and witness it passing (GREEN)
6. Refactor the code you wrote (if needed) (REFACTOR)
I spent day 2 of using TDD going through this exercise, making incremental progress on my work, with my pair sitting next to me and us switching off at each test. I would write the test, they would write the code that passes the test, and vice versa.
By the middle of about Day 2, we got to the hard stuff, the boundaries stuff. The stuff that every working programmer will run into quickly but that beginning tutorials on TDD try to ignore: Databases, user input, or frameworks that weren’t written with testability in mind. How do you write a test that is supposed to run fast (on the order of milliseconds) but you have to mock out a database or the front-end web server?
It’s like accidentally passing the bunny slopes on the ski-lift and the next stop is the double black diamonds.
I wish I could tell you this story had a happy ending, but it didn’t. I put down TDD for another few weeks due to these events, and I felt like it couldn’t be useful or help me be a better programmer. You know that part in the hero’s journey story arc where the hero is at their low point? That’s where I was.
Next time I’ll talk about about what
got me out of this low point, and how it can help all teams trying to
build better software, faster.
—
I’m putting together a course on TDD for .NET Software teams, a course meant to help teams cross the chasm I describe above. If that’s your jam, sign up to receive details and be the first to know when the course is ready (and of course the requisite early subscriber discount you won’t be able to get any where else).