3 ms·
There might be confusion about terminology here. I think of unit tests as testing contracts of individual units and then each appropriate level of abstraction h
by lfowles 11y ago
There might be confusion about terminology here. I think of unit tests as testing contracts of individual units and then each appropriate level of abstraction has its own set of unit tests. Integration tests are those that use the external user interface and represent a use case, BUT a unit test of layer N+1 could effectively be an integration test of layer N (I just wouldn't call it that if it was using a mocked layer N interface).
- jdmichal 11y ago> ... BUT a unit test of layer N+1 could effectively be an integration test of layer N (I just wouldn't call it that if it was using a mocked layer N interface). Fixing the problem of unit tests becoming de-facto integration tests is exactly what mocks are for. If you don't mock your dependencies, then you are in fact executing an integration test. The problem becomes that your mocked dependency and the real dependency can now drift because there's nothing tying them together. So a unit test works but you still have an integration bug. Personally, I think both unit and integration tests are really important, but that integration tests tend to get a bit underlooked with all the existent zeal towards unit tests. Testing a component's contract is obviously necessary, but testing that your components are expecting the correct contract from others is also important.
- lfowles 11y agoI agree, both are really important. I think integration tests get passed over because they require a higher level view of your software. Personally, in my day job, I'm not extremely familiar with the domain, so I'm pretty ineffective at writing sensible integration tests. I can, however, pass my unit tests/contracts off to the guys that are familiar with the domain so they can shape up an integration test.