Automated integration and system tests come in as many flavors as there are systems. Therefore, it’s hard to give specific advice. That said, there are a couple of generic pointers that should help.
The automation test pyramid gives us a hint about the ratio between system, integration, and unit tests. In short few system tests, more integration tests, and many unit tests. If we accept the model, we must also accept that there will be a limited number of system and integration tests.
So, how should we choose what kinds of complex tests to invest in? Here the old-fashioned notion of risk is quite helpful. What risks are we trying to reduce? What will most likely go wrong, and hurt us the most if it does? When will our customers be unhappy and when do we get bad press? Well, that’s what the system tests should be written for! The integration tests should follow a similar line of thought, although they will obviously be more technical.
Read more about these topics in Developer Testing: Building Quality into Software:
- Chapter 3: The Testing Vocabulary, pages 23-27
- Chapter 18: Beyond Unit Testing, pages 267-269
