Easy question, right? You DEBUG.
Not so fast, my friend. Actually, if you think about it, debugging is not so fast. Pretty slow, really. I’d rather do as quickly as possible.
Let’s get back to the question: A test (or three) failed, because you’ve changed the production code. How do you fix it?
Tests’ primary role is to notify you that something’s broken. The have a secondary role, which we don’t really think about often: help us fix that bug as quickly as possible.
So what do we do when a test fails?
Naturally, we look at the name of the test. This is the first clue. And why you shouldn’t name your test “Test33”. The test’s name should explain what the scenario actually tested and the expected result.
The next step would be thinking: What code did I touch? (Or, in other words: What shouldn’t have I touched?). If we run our tests regularly, like every few minutes, we’d probably know. If it’s more like a few hours or days, we won’t.
But that’s not all.
We also look around for tests in the vicinity of the tests that failed. Why are those tests passing, while others are failing? What different scenarios do they cover?
We think about all three, and try to make sense of what just happened. We want to fix the bug as quickly as possible.
So wouldn’t it be great to have something like this pop up automatically on the production code that you’ve recently changed, when you build your code?
Yes it would.
And it’s coming soon in Isolator V7. Stay tuned.
