Java What to test, and how much
The judgement questions. These separate people who write tests from people who decide what a suite is for.
4 concepts · 12 interview questions
What this topic covers
Every concept in what to test, and how much, and the questions each one gets asked as. Where a question links, it has a full write-up.
Coverage and its limits
Coverage measures which lines ran, not whether anything was checked. It is useful for finding untested areas and useless as a target.
- Is 100 percent coverage a good goal?
- What does branch coverage add over line coverage?
- What would you not write a test for?
The shape of a suite
Many fast tests and few slow ones keeps feedback quick. Inverting it produces a suite people skip, which is worse than a smaller one.
- What is the testing pyramid, and where does it break down?
- Your build takes 40 minutes. What do you do?
- What is the cost of a test nobody trusts?
Flaky tests
A test that fails sometimes trains the team to ignore failures. The usual causes are time, ordering, shared state and real concurrency.
- What causes a flaky test, and how do you fix one?
- Is it acceptable to retry a failing test automatically?
- How do you test concurrent code at all?
Test-driven development
Writing the test first constrains the design toward something callable in isolation. It is a design technique that produces tests, more than a testing technique.
- What does TDD actually change about the code?
- Do you practise TDD, and when do you not?
- What is the difference between TDD and writing tests first?