TDD
Valeriy Kuzmin, Lilt, 2020
What it is
Write a failing test
Fix it
Refactor
Key parts
- Failing test is important
- You must focus on code being testable
Some testing theory
- Identifying dependencies
- Picking equivalence classes
- Multiplying factors
- Focusing on determinism
- Pruning the outcome
- Prioritizing all above
(fake) arguments against
- This takes too much time!
- That is useless!
- I am going to miss something anyway
- But we'd have to support that
- I'll write tests later
- I'll delegate it to a QA engineer
(true) arguments against
- Developers need to be trained
- Legacy code is genuinely hard to test
- Not all code is truly predictable
- Sometimes you have to urgently refactor
So, how to apply?
- Be positive, believe in yourself, work on the habit
- Gradually introduce coverage for existing code when working on bugs
- Write new code in TDD. If you cannot, write X% of new code in TDD
- Integrate into CI (git hooks are not CI!)
- Focus on low-level testing first
- Improve and maintain the system
Recap
Benefits | Costs |
---|---|
No way to cheat | Need to allocate more time * |
Improve code quality and design | Need to care about CI * |
Less regressions * | Need to train developers * |
Better test coverage | |
More skilled developers * | |
Better predictability of work | |
Less need for dedicated QA * | |
Less integrations broken | |
Happier developers! |
Compared to no tests (*) or tests after, tests-first have...
But why? Isn't it just a theory?
- Pro: effect on productivity
- Pro: Empirical evidence
- Pro: evidence summary
- Minor: branch coverage & mutation score
- Contra: questionable coverage
- Contra: fragile tests
- Various: discussion on SO
Thanks!
Questions?
tdd-at-lilt
By Valeriy Kuzmin
tdd-at-lilt
- 279