4 ms·

I mostly agree, except that for parts of the code that meet these conditions, I aggressively unit test as the default. To the point that if an end-to-end test u

I mostly agree, except that for parts of the code that meet these conditions, I aggressively unit test as the default. To the point that if an end-to-end test uncovers a potential bug in this component, my first action is to write a new unit test for this component inspired by the end-to-end test. If that unit test fails, then I can focus on just the unit test, and not worry about the end-to-end test until the unit test passes. Another condition I would add to the list, which the component of mine I am thinking about meets is: 5) Failures in this component have cascading effects to multiple other components, causing seemingly "impossible" failures that are not obvious to others that they were caused by this component.

crdoconnor 8y ago
If your end to end test uncovers a bug in a lower level module that has a clean and stable abstraction, yes it makes sense to write a test that surrounds that instead. That needn't be a unit test. It could simply be a lower level integration test.
- JanisL 8y ago
  Reading this makes me realize I had a bias against making lower level integration tests in this situation, definitely something I'll have to look for in the future.
- scott_s 8y ago
  In some cases maybe, but it's not effective in my case. In order to catch failures in this particular component, the most effective thing is to check that a large set of invariants is still true. An integration test of some kind only checks for behavior; does this component work when interacting with the rest of the system? That can show a failure exists, but is not useful for showing why. It's the unit tests which continually check the large set of invariants that can really get to the why: if a particular invariant is no longer true, the path to the problem is usually clear. Maybe that should be a number 6): easily tested invariants.

crdoconnor 8y ago

If your end to end test uncovers a bug in a lower level module that has a clean and stable abstraction, yes it makes sense to write a test that surrounds that instead. That needn't be a unit test. It could simply be a lower level integration test.

JanisL 8y ago
Reading this makes me realize I had a bias against making lower level integration tests in this situation, definitely something I'll have to look for in the future.
scott_s 8y ago
In some cases maybe, but it's not effective in my case. In order to catch failures in this particular component, the most effective thing is to check that a large set of invariants is still true. An integration test of some kind only checks for behavior; does this component work when interacting with the rest of the system? That can show a failure exists, but is not useful for showing why. It's the unit tests which continually check the large set of invariants that can really get to the why: if a particular invariant is no longer true, the path to the problem is usually clear. Maybe that should be a number 6): easily tested invariants.