Re:Ask HN: Do you write tests before the implementation?
by ed_elliott_asc on Monday November 18, 2019 @10:29AM
(#21565014)
> (testing taxonomy is bad)
So true, it is terrible!
What I say is:
Unit tests - small tests that show the intent of one line of code or small set of lines, what the developer thought it was meant to do - can't prove correctness of an entire process
Integration tests - test one specific process works (login success, login fail, etc.) starts to prove correctness of one part of an application
Acceptance tests - larger, test that processes interact together and prove that multiple processes work
Production tests - (roll out to x users and monitor or something similar) - prove that the entire application works, in production.
Tests go from: Small to large, fast to slow, no risk to complete risk
By this I mean that I unit test (as driven out by Discovery Testing i.e mocking collaborators) down the dependency graph until I hit a leaf node, which I will integration test against real external systems or black box unit test if the logic is self contained.
This sort of drives out a world where slow tests are kept to the leaf components, or the e2e acceptance, and everything else is quick with confidence in all the paths.
It certainly does lead to a world where refactoring is more costly because of the burden of these mocks but this isn't trying to follow Chicago TDD where the refactor step is part of the cycle, instead looking like London TDD where the testing puts pressure on the design itself, so refactors are far less common.