I was tag-teaming a change with one of my teammates, Brian, and I didn’t even know where to begin. I wasn’t nearly as confident with the scheduling logic as Brian was, which is why I was really excited to partner up with him in order to make the changes we needed.
First, write tests that fail…wait, what!?!
Brian took an interesting approach to the problem. No, he didn’t open up the code and try to walk me through the method calls…instead, he opened up our test project and showed me the tests we already had written for the scheduler.
Next, we wrote a couple of unit-tests to cover the new behavior. As you can expect, our tests failed. To be honest, I didn’t really understand what Brian was trying to do…I knew the tests would fail. In reality, though, now we both understood exactly what the problem was, and we both knew exactly what the new behavior should do.
By writing our tests first, we both had a shared understanding of what the new behavior should be. I still didn’t know everything about the scheduler, but I knew everything about the change we were about to make!
Next, isolate the issue…
Now that we had tests that were failing, Brian and I added a couple of methods to our scheduler that we thought would achieve our desired behavior. We wrote enough code to satisfy our unit tests. And then we ran those tests again.
As you’d imagine, now our tests are passing. And honestly, I don’t think we saved any time by doing things in this order. However, what we did do, was isolate the issue. Our changes were minimal, and we simply added some methods to exercise the new behaviors we wanted. Pretty simple. But unit tests don’t tell the whole story, right?
Then, wire up your changes…
The last thing we did was wire up our new methods in the appropriate places. For example, we simply added the new checks to our scheduler before we actually displayed a notification to our users.
Finally, relax…
Not only is my confidence extremely high that our changes are working, I’m also confident we didn’t change any of the existing behaviors (because we already had tests for those behaviors).
Ultimately, if you want to be confident in your changes, write your tests first…go ahead, I dare you 🙂
