We tend to fear the red marks, the little indications of something wrong, the failures. We try to do our due diligence to avoid them wherever they are, whether on the paper for school, our IDE’s compiler output, or in our build pipeline. Why are we so afraid of those little failures? These failures help us to learn so much.
Failure is built into TDD
In Test Driven Design, failure is literally built into the paradigm. You are not allowed to write a single line of code until you have a failure. I think that is one of the biggest stumbling blocks to those who are new to the system. We see no benefit to running something we know will fail (and we do not want to see that failure). We don’t want to be confronted with the failure, and we don’t want to have to acknowledge it.
Even though none of us like failures, failure is a fantastic way to learn. TDD is designed to teach you through the failures, to the point of surprising you with the results. What really is the output from a test that tries to instantiate a class that does not exist? Can you say? Is it an Error or an Exception? Does it give you a stack trace? What does the stack trace look like? While only writing code after you see a test go red seems pedantic, it is there to make sure you are constantly learning.
The failure, or sometimes the lack of failure, can sometimes be very surprising. From something as simple as getting the order of parameters wrong in an “assertEquals” call, to actually getting a complex algorithm right on the first try. Sometimes just trying to think of the failure you expect will force you to take smaller steps, to break the code into smaller and more understandable bites. It is easy to reason about what a chunk of non-existent code should do, but can be very difficult to find out how it should do that.
Other Automated Tests
Larger-scoped automated tests can serve a similar purpose too, whether they are integration tests, regression tests, performance tests, etc. Running them early and often, especially when you know they will fail, can be very informative. They can be a great way to track progress, as you watch a failing test start to pass. They can be a great way to track lack of progress, or regression, as well. Perhaps you made a change that you thought would fix a problem, but it caused unintended problems elsewhere. Even though something failed, you may have learned something extremely valuable from that failure.
Do not be afraid of the build failures! Learn from them. Learn how to read the failures, and let them point out what work needs to be performed next.
Originally Posted on my Blogger site June of 2018