4 ms·

"In my experience, unit tests are most valuable when you use them for algorithmic logic. They are not particularly useful for code that is more coordinating in

"In my experience, unit tests are most valuable when you use them for algorithmic logic. They are not particularly useful for code that is more coordinating in its nature." I agree in principle, but IME: * This kind of algorithmic code often makes up a fairly small proportion (~5%) of code written for most business driven applications - it's usually mostly coordination. Some domains may be different (and for them, unit testing will appear to be much more effective), but I think this is the norm. * Integration tests can test algorithmic acceptably well, but unit tests do not test integration code in an acceptable fashion. * Where you have algorithmic and integration code smushed together (this type of technical debt is, sadly, the norm 'in the wild'), again, integration tests work acceptably well whereas unit tests require a mess of mocks. * Integration tests do not have to be high level or slow. "Refactoring breaks tests. Sometimes when you refactor code, you break tests. But my experience is that this is not a big problem. For example, a method signature changes, so you have to go through and add an extra parameter in all tests where it is called. This can often be done very quickly, and it doesn’t happen very often. This sounds like a big problem in theory, but in practice it isn’t." This is a big problem in practice when you are working on large scale code bases in which the developers have not been super strict about decoupling everything.

RHSeeger 9y ago
> Integration tests can test algorithmic acceptably well, but unit tests do not test integration code in an acceptable fashion. True, but you can have both types of tests, which lets you test algorithms (unit tests) and higher level combinations (integration tests) both in the best way. The right tool for the right job. > Where you have algorithmic and integration code smushed together (this type of technical debt is, sadly, the norm 'in the wild'), again, integration tests work acceptably well whereas unit tests require a mess of mocks. In many cases, you'd be better off separating the logic, which would let you have both types of tests, each for a different part of the logic. > Integration tests do not have to be high level or slow. No, but they are a different tool.
- crdoconnor 9y ago
  >True, but you can have both types of tests You can, but if your code is 95% coordination and 5% algorithmic, at most you'd want 5% unit tests. >In many cases, you'd be better off separating the logic Which is refactoring and if you're refactoring you need to have your code surrounded with tests to do it safely. And, once you've done that, if you've already written integration tests for that logic and they perform acceptably well, there may be no point in rewriting the integration test as a unit test.
jononor 9y ago
For well-defined algorithmic logic, I'd say one is better off mostly using existing code (usually via a library). If a library does not exist, write the function as stand-alone with tests exercising its API. Preferably release it as open source.

RHSeeger 9y ago

> Integration tests can test algorithmic acceptably well, but unit tests do not test integration code in an acceptable fashion. True, but you can have both types of tests, which lets you test algorithms (unit tests) and higher level combinations (integration tests) both in the best way. The right tool for the right job. > Where you have algorithmic and integration code smushed together (this type of technical debt is, sadly, the norm 'in the wild'), again, integration tests work acceptably well whereas unit tests require a mess of mocks. In many cases, you'd be better off separating the logic, which would let you have both types of tests, each for a different part of the logic. > Integration tests do not have to be high level or slow. No, but they are a different tool.

crdoconnor 9y ago
>True, but you can have both types of tests You can, but if your code is 95% coordination and 5% algorithmic, at most you'd want 5% unit tests. >In many cases, you'd be better off separating the logic Which is refactoring and if you're refactoring you need to have your code surrounded with tests to do it safely. And, once you've done that, if you've already written integration tests for that logic and they perform acceptably well, there may be no point in rewriting the integration test as a unit test.

jononor 9y ago

For well-defined algorithmic logic, I'd say one is better off mostly using existing code (usually via a library). If a library does not exist, write the function as stand-alone with tests exercising its API. Preferably release it as open source.