> You could also just test everything with manual QA. Literally pay some humans to click through your application following a defined path and asserting outcomes. Every time you make a change.
How to see if someone is arguing in bad faith? Well, they pretend that reductio ad absurdum is a valid argument
> Obviously all of these have different costs. And obviously, testing a pure function with unit tests (whether example based or property based) is going to be cheaper than testing the behaviour of that same function while incidentally testing how it integrates with its collaborators.
Let's see. A single scenario in an integration test:
- tests multiple code paths removing the need for multiple unit tests along that code path
- tests externally observable behaviour of the app/api/system is according to spec/docs
- tests that all units (that would otherwise be tested in isolation from each other) actually work together
This is obviously cheaper. Programmer (the expensive part) has to write less code, the system doesn't suddenly break because someone didn't wire units together (the insanely expensive part, 'cause everything was mocked in tests; unironically true story that hammered the final nail in the coffin of unit tests for me).
By the way, here's what Kent Beck has to say about unit tests: https://stackoverflow.com/a/153565
--- start quote ---
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence
--- end quote ---