Clean Test Code

You might think it’s just test code, this can be done quickly and dirtily. It doesn’t run in production; it’s just for me. I don’t have to write it as clean as my production code. But that’s wrong. Test code needs to be written as cleanly as production code for several reasons.

Readability

Test code needs to be readable, because you need to understand the test when it fails. Imagine you do a change to your code, you execute the tests, and one test fails. That’s great because that’s the reason the tests exist. But now you have to check why the test fails. Is it correct that the test fails because the test was written for different requirements? Or did your change introduce a bug? Now it’s necessary to read the test and fully understand it. But that’s hard if your test code was written quickly and dirtily.

Changing requirements require changing the test

When requirements change, you need to change the code to implement the new behavior. That’s why we want to write our code as cleanly as possible, so it’s easy to do that. But now the tests fail, because they were written for different requirements. So they need to be adjusted. That’s hard to do if tests are written quickly and dirtily.

Consequences of messy test code

There is a risk of losing your test suite completely. If requirements change and tests are not adjusted to the new requirements, they always fail. That’s bad because now you got a test suite with failing tests. A failing test is great to indicate a bug that should be fixed. Otherwise, you can’t tell by running the tests if your application works correctly. That’s the same as without tests. You maybe delete the tests or don’t execute them anymore. But you end up testing the application manually with all drawbacks. All efforts invested in the test suite are lost.