After writing a post for the Upsource blog about evaluating tests during code review, I found myself compelled to write something more general on why we should be writing automated tests. If you already know the value of tests, you might find something here that will help convince your colleagues who are less sold on the idea.
Why do we write automated tests?
In my first post about code reviews, I mention that a lot of activities we often do in a code review can be automated - checking style, formatting, code coverage etc. The nice thing about automating these things is that, once automated, you no longer need a human to give you confidence that your code meets certain criteria.
Tests provide us with a similar level of security. Once you’ve written some automated tests that prove your code behaves in a particular way, provided they are running in some sort of Continuous Integration environment like TeamCity, they continue to give us confidence in the code well into the future, as long as they are passing.
Another reason to have automated tests is that often the tests can be easier to reason about than the production code – they should state the desired functionality clearly, they should be readable, and they should provide insight into which things the author of the code has
considered (and possibly hint at areas they have not thought about).
What sort of tests are we talking about?