I’ve been preaching TDD for years, and one of the lessons that I’ve taught over and over is that if a test is hard to write, you have probably bitten off more than you can chew. Comment out this test, try a smaller byte, and come back to this test later.
I need to listen to myself more often
It has always been difficult for me to explain to students how TDD works with multiple objects, refactoring, stubs, and the whole shebang. They get the refactoring part, they get the writing a test and them some code part, but their understanding falls apart when I start talking about testing void methods. This is where test doubles of some sort come in, and I swear, I’ve seen more blank stares when I explain this than I have any other time in the rest of my 42 years.
So I did something about it this class.
I took my own advice.
Instead of having a big jump from TDD on a single class to this whole-hog example, I put in a couple of smaller examples, with exercises, between the two existing endpoints. In the first one, I introduce a test double that allows them to test that the side-effect of calling a method happens correctly. It takes a single interface and a single stub to implement this new concept, and they get it! Then I introduce another stub that provides data into the class under test, which requires another interface and stub class. And they still get it! Now we’re at the point where we’d be previously, but I don’t see any blank stares. Victory!
If a test is hard to write, then you’ve probably bitten off more than you can chew. Comment it out and try a smaller byte.
That advice works for the instructor, too!