4 ms·
System level integration tests are also proof that the work we did is correct and we can move on. And it is better proof than unit tests, because we aren't moc
by vigilant 10y ago
System level integration tests are also proof that the work we did is correct and we can move on. And it is better proof than unit tests, because we aren't mocking everything. And they are far more likely to survive a large and risky refactor than unit tests.
Don't confusing testing in general with unit testing. Just use the right tool for the job. If your unit tests aren't catching a material number of bugs compared the the effort spent, compared to other testing methods, then don't do them. Unit tests have benefits such as quicker execution time, etc. - but that has to be weighed against cost.
- srj 10y agoSystem level integration tests also tend to be more flaky. Both unit and integration tests are useful. Unit tests are also pretty quick to write once you have the mocking setup.
- kitsune_ 10y agoThat's one of the dirty little secrets with end to end tests that almost no one talks about. You will probably spend more time running after ghosts in the machine than finding actual bugs.
- Arnt 10y agoI've had that experience too. But also the opposite. I've worked both on code where writing the tests was more effort than the code, and on code where writing the tests was easy, quick and helpful. The latter makes sense, after all a good test is straightline code, zero ifs, zero loops. But the former? I think the key is that mocking should be used sparingly, but without hesitation.
- crdoconnor 10y agoPlenty of people talk about it: http://googletesting.blogspot.co.uk/2015/04/just-say-no-to-more-end-to-end-tests.html http://googletesting.blogspot.co.uk/2015/04/just-say-no-to-m... The dirty little secret that nobody talks about is the cause of the ghosts: poorly engineered tests.
- beefsack 10y agoThey usually tend to be quick to run too; integration tests are rarely fast enough to run during development.
- crdoconnor 10y ago>System level integration tests also tend to be more flaky. That's usually a sign that they've been engineered poorly or you have bugs in your code. System level integration tests need appropriate environmental isolation and solid asynchronous & multithreaded code. Nobody can be bothered to write these properly for tests, hence the flakiness ("ooh let's just insert a sleep here" / "eh, does it really matter which version of postgres we run?").
- BurningFrog 10y agoThe biggest benefit of unit test isn't catching bugs, but making aggressive refactorings possible.
- chrismorgan 10y agoHuh. Here was me thinking that was what static type systems were about. ;-)
- daveguy 10y agostatic type systems != unit tests
- BMorearty 10y agoStatic typing does not allow you to refactor code with confidence that you didn't break the application logic. Only automated tests can do that, regardless of type system.
- chrismorgan 10y agoSure. But an awful lot of failures in refactoring in dynamically typed languages would be avoided by a static type system. As it happens, I am a Rust fanboy with all that entails, so I (like everyone else in such discussions) am clearly biased. My point was in jest, as the “;-)” (because HN simply discarded a U+1F609) indicated.
- crdoconnor 10y agoThat's what strong type systems are about. A strong explicit dynamic type system with appropriate tests can track down bugs more easily than a statically typed weak type system.
- goldenkey 10y agoOne could also say that bad unit tests make aggressive refactoring impossible. Both sides of the coin don't necessarily make for a persuasive argument.
- 10y ago