You don't inject for tests
blog.arkency.com
You don't inject for tests
1–10 of 14 posts
Re: You don't inject for tests
#2I "discovered" DI when learning about Unit Testing, but the benefits to maintainability were obvious from the get-go.
I'm not sure many people argued that it wasn't about maintainability. I'd say they just ignored that part of the argument.
The best explanations of Unit Tests I've seen also explain how it helps improve maintainability, so perhaps that's why Unit Testing and Maintainability has always gone hand-in-hand in my thinking.
Re: You don't inject for tests
#3It's like removing magic constants from business logic into config files :)
Re: You don't inject for tests
#4It's like removing magic constants from business logic into config files :)
Yeah, I was thinking about this recently. All of the "good patterns" turn your code into data. At the end it's more of declaring than coding the logic.
Re: You don't inject for tests
#5No need to read such a post...
Title says: "You don't inject for tests"
And, before opening the link, you know what you're going to find.
Someone confusing "testing" and "unit testing".
First thing that came to my mind (while reading the header on HN) was "There are several kind of testing..." but... Curiosity killed the cat. Let's open the link.
Ouch, first sentence:
"What is unit testing for?"
OK, closed.
Don't waste your time reading this crap ; )
Re: You don't inject for tests
#6I think we are starting to argue about semantics here. This example is simply a very common way of coding to an interface, which BTW, duck-typing makes this so much easier.
I think through out the whole discussion about DI in the past week or so is that people don't talk about the injectors themselves enough. Too many pseudo-experts talking about inconsequential and totally unrelated programming principles and paradigms.
I don't think people naturally object to coding to the interface, which this example illustrates very well its utility. I think detractors simply just hate the injectors, the people who use the bad injectors indiscriminately, and the stubborn people who insist on doing DI on an entire app.
My guess is, most people automatically jump to a DI framework not really because of DI, you can do DI with just a good old factory and may be a good configuration library. Most people jump to DI because of a framework, and the niceties that said framework offers. After a while, people just start confusing the effect with the cause.
Can we please start talking about what is DI, when would one find it useful, and what DI approach is suitable under what circumstances now?
Re: You don't inject for tests
#7No need to read such a post... Title says: "You don't inject for tests" And, before opening the link, you know what you're going to find. Someone confusing "testing" and "unit testing". First thing that came to my mind (while reading the header on HN) was "There are several kind of testing..." but... Curiosity killed the cat. Let's open the link. Ouch, first sentence: "What is unit testing for?" OK, closed. Don't was…
I'm not sure I understand what you're so upset about?
"Don't waste your time reading this crap" because of some imprecise verbiage?
According to the typical "testing pyramid", unit testing should be the most common type of testing done -- is it really so unforgivable that someone would use a general term (test) for what they do most often (unit test)?
Re: You don't inject for tests
#8No need to read such a post... Title says: "You don't inject for tests" And, before opening the link, you know what you're going to find. Someone confusing "testing" and "unit testing". First thing that came to my mind (while reading the header on HN) was "There are several kind of testing..." but... Curiosity killed the cat. Let's open the link. Ouch, first sentence: "What is unit testing for?" OK, closed. Don't was…
I scoped my blog just to unit tests, because it's short note rather than article. DI can be useful on integration and acceptance level too - for simple apps you should be able to configure whole app or its parts as easy as you run it on production. Without DI you have to do some magic with class / module constants, which can populate on other parts.
Re: You don't inject for tests
#9Can someone not work out a way to 'unit test' dependency injection vs other methods so we have some facts to compare? These discussions feel like people arguing with each other over which color is the best, with everyone chiming in with random anecdotes and feelings.
Red must be the best - it goes the fastest!
Re: You don't inject for tests
#10It would be quite hard to draw a straight line to separate goals of software creation and maintenance.