[qwertyuiop12]

If you have a qa team, perfect. But I don’t recommend to follow this way.

Many code is slow due to it has a couple of wrong implementations, such as rendering or make something heavy all the time when you have to do it only one time.

There is no problem to create a decoupled system using di, the final performance it will be tolerable.

Also, you have the possibility to create custom builds with tests and good practices in the main branch.

[bcrosby95]

DI is the biggest snake oil out there. The vast majority of time it's just used as a hack job to enable test isolation in weak languages and gives you no real-world decoupling.

Sure it's sometimes necessary, but I wish people would stop with the expostfacto justification. It doesn't make your code better if you add it just to test your code.

[porker]

> DI is the biggest snake oil out there. The vast majority of time it's just used as a hack job to enable test isolation in weak languages and gives you no real-world decoupling.

Have you got any data or writings to back this up? I ask because what you write is my gut feeling but I can't put it into words or convince anyone.

That I have ended up programming in an area where the answer to testing is "spin that into its own class so it's testable" when the code is used in a single place, would be fine as a private or protected method, but still needs tests to confirm the output is right, drives me crazy. For libraries sure, but for checking the date parsing is right, that you didn't mess up the calculation... just let me test the damn protected method and be done with it.

Hundreds of tiny classes benefits no one, only the testing framework.

[selfhoster11]

I agree with this. FWIW, Java (for instance) could treat testing as a privileged mode of execution, allowing for all properties (even private ones) to be get/set/interacted with as if they were public, for the duration of the test. This would simplify so many things and get rid of so much boilerplate code.

[kaba0]

I agree actually and was thinking that visibility modifiers should not really deny access for the internals of the class under testing. Maybe c++’s friend classes would be a good solution? Or I don’t really find groovy to be the best thing, but it could probably be hacked to translate private accesses to reflection calls under the hood making testedClass.privateField actually callable?

[ivanche]

I'm interested in your proposal for an alternative. Service Locator? New operator everywhere, used at-will? Something else?

[selfhoster11]

Allow all properties and methods to be get/set/called freely by the test harness (such as JUnit in Java's case), as if they were public all along. The need for DI in testing would be greatly reduced, while keeping the public/private distinction intact while the code is running as normal.

[commandlinefan]

> the final performance it will be tolerable

I had the same thought - if SO says they're fast because they don't use DI, then ok, maybe SO is fast because they don't use DI AND they have an elite group of amazing full-stack programmers who write OS kernels and prove that P != NP over their lunch break for fun. Most programmers fuck things up on a regular basis and don't even realize it until it's broken production for a couple of years for a handful of users who go down a non-standard path every once in a while, and they do it in a way that would have been caught if the code had been run even one time, but they can't run the code, because somebody else insisted on using a hundred static (i.e. global) variables.