I am talking about these two testing strategies :
- Have a pyramid of tests (with many more unit tests than high-level tests), because high level tests are harder to maintain and slower (see also : https://blog.octo.com/the-test-pyramid-in-practice-1-5/)
- Test behaviors (high level tests), not implementation details so that refactors don't break your tests when initial input and final output and general behavior are the same.
For me, it looks like those concepts are contradictory.
Here is a concrete example : let's say I have 2 local models, DTOs (close to API) and entity model (close to database structure).
Now I have mappers dto <-> entity automatically generated (using MapStruct, Orika, ...), if I rename an attribute in one of the model (even using automatic IDE refactor), it will still compile and I will still have the same input/output objects but it will break my system details (the attribute won't be mapped through the generated mapper), so it seems like it's useful to write a unit tests for each mapper (which would be very tedious and defeat the purpose of having the mappers auto-generated in the first place).
On the other side, if I write only integration tests going through all my layers, I'm not respecting the "pyramid of tests" recommended strategy.