Forms of Automated Testing

Unit tests are intended to verify very small units of code, for example, a function, or a method. We want our unit tests to reach a very detailed level of granularity, testing as much code as possible. To test something bigger, such as a class, we would not want to use just unit tests, but rather a test suite, which is a collection of unit tests. Each one of them will be testing something more specific, like a method of that class.

Unit tests aren't the only available mechanism of automatic testing, and we shouldn't expect them to catch all possible errors. There are also integration and acceptance tests, both of which are beyond the scope of this course.

Integration tests vs. acceptance tests

In an integration test, we want to test multiple components at once.

In this case, we want to validate if, collectively, they work as expected. In this case, it is acceptable (even more than that, it's desirable) to have side effects, and to forget about isolation, meaning that we will want to issue HTTP requests, connect to databases, and so on. While we want our integration tests to actually run as the production code would, there are some dependencies we still want to avoid. For example, if our service connects to another external dependency via the internet, then that part would indeed be omitted.