3 ms·
Dependency inversion with the aim of writing unit tests is helpful for logic or calculation heavy chunks of code but for everything else it actually makes the c
by MoreQARespect 3y ago
Dependency inversion with the aim of writing unit tests is helpful for logic or calculation heavy chunks of code but for everything else it actually makes the code less maintainable.
It balloons the size of the code base and as a reward you end up with a ton of mimetic tests that mirror the code and dont actually catch any bugs.
- DarkNova6 3y agoI'm sure this approach can be applied to some problem domains better than others. If you have a simple CRUD app, then yes there isn't much you can check. But even there, you can at the very least mock the responses of the database (or other external systems) and check if the data in your response is as expected. Naturally, this works best if you work with structured data or have a well-defined domain. In case of a well defined domain, you can just mock the domain models don't even touch the module which talks to the outside world.
- MoreQARespect 3y ago>But even there, you can at the very least mock the responses of the database (or other external systems) and check if the data in your response is as expected. You certainly can but these tests end up mimicking the implementation rather than actually testing the code. A pure CRUD app - even if it's relatively complicated - should have zero unit tests.
- DarkNova6 3y agoI guess you can technically test everything in a CRUD app as integration test. Doesn't mean you should. Surely, you have a baseline of verification/validation logic for which unit tests are the best fit. And based on my experience of my last project, if you can't do proper unit testing you likely have the wrong granularity in your methods and classes.