Tests that cover more than one unit are hard to maintain and sometimes duplicate cases already covered by other tests. A lot of projects struggle with large suits of acceptance, integration and system tests that fail regularly and take a lot of effort to fix. When is an investment like this justified?
While the definition of a unit test is commonly known and accepted, other tests towards the top of the testing pyramid are known by different names and their scope isn't obvious.
Acceptance, integration, end-to-end, system, component tests - those terms mean different things in each project or team. Why do we believe that everyone understands the testing pyramid and automatically knows how those terms are defined?
This talk will show a simple way of finding a common understanding of those terms in your team. Additionally, we discuss which automated tests are generally questionable and when they are necessary.
I am discussing the lack of understanding and use of Mike Cohen's testing pyramid.
I show an example system and talk about which tests are useful in which scope. I discuss the merits of acceptance tests and different integration tests. I stress the importance for a clear testing strategy when it comes to automation.