6 ms·
DI is bad, what? So how are you writing tests then.
by hacker_9 8y ago
DI is bad, what? So how are you writing tests then.
- tonyedgecombe 8y agoI always though dependency injection was an inevitable product of over zealous testing. As soon as someone says we need to test 100% of the code in our UI that is where you end up.
- hacker_9 8y agoNo it's just an inevitable product of 'testing'. It's a simple way to enable and disable dependencies. There is literally no better way, apart from not having any dependencies in the first place of course.
- Spearchucker 8y agoLike in procedural languages I write my own harnesses as needed. Because DI adds complexity. And for testing all DI does is make testing easier. You end up shipping all that complexity or you refactor your ship code. To be fair that might be acceptable to many in a typical corporate environment.
- vietjtnguyen 8y agoWhat do you mean by DI? I find DI is an overloaded term.
- ahansen 8y agoIn this context I believe he is referring to dependency injection.
- vietjtnguyen 8y agoI guess I meant to ask what they mean by dependency injection. A bare version is just passing dependencies as arguments and I can't imagine what is so egregious about that. Maybe they mean something more complicated?
- steveklabnik 8y agoGiven "I write my own harnesses as needed", I read the parent as talking about DI frameworks, not the general concept of DI. https://en.wikipedia.org/wiki/Dependency_injection#Dependency_injection_frameworks https://en.wikipedia.org/wiki/Dependency_injection#Dependenc...
- hacker_9 8y agoWell you are going to need to deal with your dependencies eventually. Unless you are just end2end testing, and not doing any unit tests. In that case good luck finding your bugs when they appear. Or perhaps you write 'if (mode == "test")' everywhere :)
- MarkMc 8y agoBy letting the application load all required components into memory before running the test(s). If Component A needs Component B which needs Component C, they all get loaded as they would in production (ie. without mocks). If this means that almost the whole application gets loaded to run a single test, so be it. The only time this approach is really a problem is when doing slow calls such as I/O - eg. writing to the database. In such cases you can easily switch to an in-memory database or use a factory pattern (which is kind of like a hand-rolled mock). It's true that an error in say Component C may generate many failures in test of for other components, but in practice that's not really a problem. Just pick one of the test failures and drill down until you find the root cause - fixing that cause will magically fix the other 55 test failures.