As usual, I was pairing with my co-worker solving a problem. But this time I noticed something subtle but could be important which I often over looked from before… at least for me.
We were creating a new Command object. Writing code test-first seems to serve us well in the past in driving out the design, so the first thing we did was writing a test for this Command object.
Later, it was apparant to us that this Command object needs to collaborate with an existing Service, sending it a new message (API method that does not exist yet). Staying in the test, we expressed the collaboration as a JMock Expectation of the Service. In order to get the test to run JMock requires us to change the Service interface. And of course, when we did that, the ever diligent Eclipse compiler gave us quite a few errors along the lines of how the various implementations of our Service failed to implement this new API method. Not surprised.
Now what we decided to do next was what I find interesting…
Rather than going to find all the implementations to “QuickFix” the complier error. We decided to switch back to the test and “ignore the pesky compiler error”.
We then continued our design inside the tests; running the tests; and writing the Command code to fix the tests and repeat. And we were done with the Command. And we were very productive!
Hmmm, what about the compiler errors, yes, the ones we chose to ignore before. They are now acting as a reminder for us – we now need to focus on the Service API implementation.
What I realized afterwards is this might have something to do with how it helped us focus on our tasks. By ignoring the compilation errors allowed us to focus on designing the “Object Under Test” and minimized context switching.
Side bar: I always got into a habbit of getting all my code to compile and then run my tests. Pyschologically, I kept thinking our tests can’t possibly run without everything is compiled. But it is not true! We proved it.
Another thing was, keeping the “design/test/code” rhythm going (I am calling it a rhythm because I don’t know what the proper notation for this yet) is crucial in practicing test-first development. This rhythm is fragile in a sense that if we are not paying attention to it, we could easily slip out of the rhythm. And it would be hard to get back in to the beat. Next thing we know, we find ourselves doing code-first development again.
I realize everyone can find different ways to get into the rhythm but this seems to be working for me 🙂