3 ms·
I'm not the original poster, but I find that integration tests have a far larger payoff than unit tests, in general. A good release process that tests differen
by ori_b 14y ago
I'm not the original poster, but I find that integration tests have a far larger payoff than unit tests, in general. A good release process that tests differences in behavior between a test system and the current version of the service in production is also valuable.
Being able to test that the whole system works as intended gives a better return on investment, in my experience, than testing small bits in isolation. The errors are, often as not, in the glue between the small bits.
- t_hozumi 14y agoAgree, integration test is cost-effective. And I would like to rephrase "integration test" as "test from outside as much as possible".
- plorkyeran 14y agoThe main advantage I've found from testing little bits in isolation is that it tells you a lot more about where exactly the bug is. However, there's no reason why you need to write them in advance to get this benefit. The general workflow I've grown fond of is to write mostly higher-level tests that test the system as a whole, and then only write fiddly unit tests when there actually is a bug to fix. Those unit tests then stick around, but I don't feel bad about blowing them away without replacing them if the thing being tested changes significantly enough to make them useless.
- chii 14y agounfortunately, integration tests tend to take a longer time to run. unit tests tend to run instantaneously.
- pkolaczk 14y agoUnit-tests work great for us for testing some well isolated pieces of complex logic with a simple API (e.g. algorithmic stuff). But we don't unit-test things simple like getters or setters or code that is glue between components and just delegates real work to some other components. For this, we do functional / integration testing and it plays well.