Section 8.1 Automated Testing
Let us briefly talk about automated testing in general. Our goal is simply this: We want to be able to press a button, and a few minutes later get back a message telling us either "everything works as prescribed" or "here is a problem". This is exactly what automated tests are.
Automated tests run without requiring any user input or inspection, and at the end report either "everything OK" or "here are some problems". You should not have to look hard at the results of the test to know that everything was OK. And if something was not OK you should be able to know exactly which test lines caused the problem.
There are many different kinds of automated tests, we will single out just a few:
- Unit tests are there to tell you that a specific class/function doing its job properly.
- Integration tests are there to tell you that the various parts of your system are glued together properly.
- End-to-end tests are there to tell you that your system behaves correctly on the user’s end, and they test the whole path from the user’s request to the results the user gets back.
- Acceptance tests are executable tests written in a language that your clients can understand and verify that it matches their specifications.
In this book we will focus mostly on unit tests, and perhaps a bit on integration tests. These are the workhorses of the test-driven-development process.
