Chapter 1 of 8 · 4 practices · 4 min · 3-question quiz
Choosing what to test and at which level
Every test has a cost and a level. This chapter covers the test pyramid, pushing tests to the lowest level that can catch the bug, and testing behaviour instead of implementation.
Start: Shape the suite like a pyramid: many unit tests, fewer integration tests, very few end-to-end tests4 practices in this chapter
- 1Shape the suite like a pyramid: many unit tests, fewer integration tests, very few end-to-end testsThe test pyramid groups tests by how much of the system they exercise. As Martin Fowler's article on the practical test pyramid puts it, the more high level you get, the fewer tests you should have.
- 2Push each test to the lowest level that can catch the bugEvery test you write has to be maintained, so avoid checking the same thing at several levels. Fowler's advice is to push tests as far down the pyramid as you can. A validation rule for an email…
- 3Test observable behaviour through the public interfaceA test should describe what the code does for its callers, not how it does it. Tests that reach into private methods, assert on internal data structures or check the exact order of internal calls…
- 4Spend tests on logic and risk, not on trivial codeNot every line deserves a test. Getters, setters and plain data mappings with no branches add maintenance cost and very little safety. Fowler warns against testing trivial code just to raise a…
Check yourself on this chapter
3 questions, right here once you are signed in. Your progress is saved as you read.