3 ms·
Do you find this results in less overall test code to maintain since you likely have fewer but higher quality/signal tests?
by trevor-e 3y ago
Do you find this results in less overall test code to maintain since you likely have fewer but higher quality/signal tests?
- simonw 3y agoYeah - I find that sticking to tests like this means I don't have hundreds of tiny unit tests that rely on mocks, and it's still very supportive of refactoring - I can make some pretty big changes and be confident that I've not broken anything because a given request continues to return the expected response.
- gorjusborg 3y agoThe choice isn't unit tests vs . end-to-end tests, its between testing things you don't really care about and those you do. You care about real use cases and verifying design constraints are met. You don't care about internal implementation details. The nuance is that there are often things one cares about at multiple levels.
- stingraycharles 3y agoYes, you just focus on a few high level behaviors that you want to validate, instead of the units. It’s more difficult to pull these tests off, as there are more chances for them to become flaky tests, but if they work they provide much more value. I’d prefer a dozen well written integration tests over a hundred unit tests. Having said that, both solve different problems, ideally you have both. But when time-constrained, I always focus on integration tests with actual services underneath.