9 ms·

>If you focus on integration test technology like Cucumber or headless browser drivers, they will absolutely balloon your test suite runtime and it is partly be

>If you focus on integration test technology like Cucumber or headless browser drivers, they will absolutely balloon your test suite runtime and it is partly because they are extremely inefficient Between unit tests (fast, unrealistic, tightly coupled, catches fewer bugs) and integration tests (slower, more realistic and catches more bugs) I virtually always pick the latter. I'm happy to trade CPU churn for "catches more bugs". CPU time is cheap.

pmarreck 7y ago
It is not a dichotomy. Ideally you’ll have lots of unit tests and a few integration tests, all valid. I’m scarred by seeing test suite runtimes (THE most important element of programmer productivity IMHO) completely balloon after focusing too much on integration tests. There is a world of productivity difference between a 1 minute test suite and a 40 minute (or 4 day) test suite
- pytester 7y ago
  >It is not a dichotomy. It is a dichotomy. You do not want the same thing being covered by two different types of test. Duplicated test coverage means duplicated maintenance. >There is a world of productivity difference between a 1 minute test suite and a 40 minute (or 4 day) test suite Not in my experience. Tests can easily run while I'm at lunch, overnight, working on something else or, if time is really of the essence, in parallel. If I'm running an individual test while developing anything that runs in under a minute has no effect on my productivity. Tests that don't catch bugs are a far, far bigger deal.