The testing pyramid organizes automated tests by how much software they exercise. Start with focused tests for individual components, then test cooperation between components and finally verify required behavior. The exact shape varies: different teams use three to seven levels and different names. section 8.1.1
Figure 8.1 Hierarchy of testing categories
Use the hierarchy diagram to compare testing categories by scope and see how the levels relate. section 8.1.1
The named levels describe increasingly broad checks:
- Unit tests exercise one component, typically a single function. Keep them independent, minimize side effects, and make their results unaffected by execution order. section 8.1.1
- Integration tests exercise several units together and check whether their cooperation produces the desired result. They may also be called system tests and usually stay at the business-logic or server level rather than the GUI. section 8.1.1
- Behavioral tests map directly to requirements and verify that a feature performs its intended action. Acceptance tests is another common name, and Cucumber is a framework associated with this level. section 8.1.1
- Django projects can also be tested at the user-interface level, although doing so requires more work than the unit and integration levels. section 8.7
A database side effect
A function-level test is easiest to keep independent when it avoids changing shared state. Writing to a database is a side effect, so deciding whether that behavior belongs in a unit test requires care; broader integration coverage may be more appropriate. section 8.1.1
