3 ms·

When I unit test, there is normally not much going on in the “unit” besides its use of dependencies, so the tests are largely circular (asserting things about m

When I unit test, there is normally not much going on in the “unit” besides its use of dependencies, so the tests are largely circular (asserting things about mock expectations). I still have to write them, because Thou Shalt Have Unit Tests. I can’t consolidate the overly-trivial units, because that would not be Architecture Best Practices, and might even be Spaghetti Code.

koyote 5y ago
> besides its use of dependencies Isn't that sort of the point of the unit test in that case? You test the use of those dependencies: Write a test where a mocked dependency returns something unexpected and see how your 'unit' responds. This is why mocks are useful because often you rely on implementation details of your dependencies and only test the happy cases. With a mock you can return whatever edge cases you come up with and ensure your unit handles everything as expected.
- closeparen 5y ago
  No? The point of a unit test is to tell me something non-obvious about how the function behaves in certain circumstances. When unit testing glue code there is no information in the test result that is not also literally written out in the unit under test (it makes these calls in this order).
christophilus 5y ago
The way I think about tests is: what’s the cost of failure here vs the cost of testing? Sometimes, bugs in this part of the codebase would not be a showstopper, so why test as heavily? The most important tests by far are smokescreen integration tests for critical paths through the system. I tend to care much less about other tests in many cases. Obviously, if I was writing a compiler or database or medical software, that’d be different. But I’m generally writing web applications where if the entire application were to fail for a day, we probably wouldn’t even lose a customer.

3 ms·

When I unit test, there is normally not much going on in the “unit” besides its use of dependencies, so the tests are largely circular (asserting things about m

by closeparen 5y ago

koyote 5y ago
> besides its use of dependencies Isn't that sort of the point of the unit test in that case? You test the use of those dependencies: Write a test where a mocked dependency returns something unexpected and see how your 'unit' responds. This is why mocks are useful because often you rely on implementation details of your dependencies and only test the happy cases. With a mock you can return whatever edge cases you come up with and ensure your unit handles everything as expected.
- closeparen 5y ago
  No? The point of a unit test is to tell me something non-obvious about how the function behaves in certain circumstances. When unit testing glue code there is no information in the test result that is not also literally written out in the unit under test (it makes these calls in this order).
christophilus 5y ago
The way I think about tests is: what’s the cost of failure here vs the cost of testing? Sometimes, bugs in this part of the codebase would not be a showstopper, so why test as heavily? The most important tests by far are smokescreen integration tests for critical paths through the system. I tend to care much less about other tests in many cases. Obviously, if I was writing a compiler or database or medical software, that’d be different. But I’m generally writing web applications where if the entire application were to fail for a day, we probably wouldn’t even lose a customer.