|
While INowResolver seems like overkill, sometimes tests need to fix the time to get reproducible behavior. I find using the registry is similar, as are really any external data stores or sources of info, ie random numbers too.
Unit tests should never rely on external input to work correctly. MUCH easier said than done.
So I get it, and I also get where you're coming from. It's certainly a shock to the system when you're used to the ease of static methods.
Good luck with it!
|
|
|
|
|
al13n wrote: Good luck with it!
Thanks! :P
|
|
|
|
|
Has everyone written their Y2.038K unit tests yet? We don't want to wait till the last minute, like Y2K, when the legacy 32-bit time_t range is about to run out. 
|
|
|
|
|
I'm sure just like everything else it's going to become an anti-pattern.
I love it though. Not in the, "I'm going to use it everywhere!" way though. Like every coding choice there should be a good reason when you apply it.
In ways, it's one of my problems with async-await. It's great except how it creeps like a fungus where you don't want it. Not to get off topic.
|
|
|
|
|
Exactly! There is such a thing as too much of a good thing!
|
|
|
|
|
The rule of thumb I use is pretty simple. If i'm designing a class that depends on some other class, and there is a logical reason for that class to change either at runtime or in testing then I use dependency injection.
I also use DI when it makes sense to control something at runtime, such as a configuration entry, connection string, etc... or anything I might otherwise use a factory for.
Your example above for INowResolver seems kind of silly at first glance, but in reality, it's a great example of a DI resource. The problem with DateTime.Now is that you cannot alter this in testing, it always uses "Now" even when you might want to use a different time for "Now" (think when you want to test what happens in 2037 when the Y2037 bug hits, you can now substitute INowResolver with a different date/time for "now" to test what will happen in the future). Yes, you could write conditional code in your method to deal with this, but now you have test code in your methods, rather than in your test cases, which makes them messier and more difficult to maintain. There are also "Moles" or Proxy stubs that can replace the runtime behavior of methods like DateTime.Now, but not everyone uses those.
Your problem here is that you're not truly understanding the purpose of Dependency Injection, and as such you have a hard time understanding why it's used so much. You probably see it as a simple service locator or abstract factory service... injecting stuff so you don't have to bother typing "new". While it's true that you can use it for that, it really opens up a whole new array of possibilities when you "drink the Kool-Aid".
As for your Utility functions... in general, no.. you don't need to use DI for utility functions if there is no configuration or other dependencies involved. Particularly if they are pure static methods with no state.
--
Where are we going? And why am I in this handbasket?
|
|
|
|
|
No, my problem is always it COULD be used in theory to do... some special things...
Which I haven't seen BEEN put into practice...
(which is to be expected when there is a combinatory explosion of mock call to write equals to number of method to test times number of interface method to mock!)
But enough, I am not here to argue, on the contrary!
You love dependency injection! Wonderful! Me too! Gonna write no more public constructor or static class for the foreseeable future ever!
modified 12-Feb-15 1:49am.
|
|
|
|
|
First off, stop wanting to be an ass kisser. No good ever came from wanting to kiss someone else's ass.
Second, I'm always suspicious whenever I see a technology being used everywhere throughout an application. It makes me think that they don't really know how to use it properly.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: First off, stop wanting to be an ass kisser. No good ever came from wanting to kiss someone else's ass.
Well in "The Economist" they boasted the virtue of networking, which can be expediently describes as ass kisser... Clearly I need to work on my networking too, as I suffered greatly last year from expressing my opinion (main customer doesn't want me anymore) and nothing came out of it anyway!
Further it appeared to me that skill and work will only take you so far...
Dominic Burford wrote: Second, I'm always suspicious whenever I see a technology being used everywhere throughout an application. It makes me think that they don't really know how to use it properly.
I think so too! But it's obvious unless I can win the battle I better leave the boat or join the bandwagon. Arguing left me in a bad spot.. I'm tired of arguing... It only cause me trouble and people don't listen... Further I'm quite contended now, so I don't have a pressing need to find the best tool, I think I already played with it!  and I am ready to go on board financially with people who still resist them!  
|
|
|
|
|
There is a wide gulf between networking and getting on with your colleagues, and ass kissing. Ass kissing is where you subjugate power and influence to another individual. Getting on with other people doesn't mean you have to agree with everything they say and do. I have many disagreements of opinion, but I am always assertive in expressing those differences, whilst simultaneously being courteous.
Stop ass kissing and start being assertive. You'll win far more respect.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Super Lloyd wrote: Further it appeared to me that skill and work will only take you so far...
All that matters is whether someone can sell it. Doesn't need to work well. Doesn't even need to run. But absolutely must sell. Unless of course you like working for free.
Super Lloyd wrote: and people don't listen.
Yep.
Realistically the idiom that you are using now is unlikely to adversely impact the running of the product. Costs more in maintenance and adds complexity. And in my experience over time it tends to make the code more like structured code and less like OO code.
But none of that can be quantified as a real cost. Or at least it is a good bet that your company can't actually measure maintenance costs and never will.
So just do it.
|
|
|
|
|
Dominic Burford wrote: First off, stop wanting to be an ass kisser. No good ever came from wanting to kiss someone else's ass.
Too be fair a lot of this stuff normally only adds to maintenance costs and since the vast majority of organizations can't quantify maintenance costs anyways attempting to buck those in charge usually is nothing but a waste of time.
Dominic Burford wrote: It makes me think that they don't really know how to use it properly.
Yep.
|
|
|
|
|
I find it, in general, a pain in the arse.
Regards,
Rob Philpott.
|
|
|
|
|
When two ways work, but I find one, shall we say "inelegant", I do it both ways, and run performance tests.
Here's the important bit: If the performance tests show that my preferred way doesn't give a worthwhile improvement, I drop the subject.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Use Dependency Injection wherever there will be a need to swap out an implementation.
- Injecting different configurations
- Dynamic loading of functionality
- Replacing an implementation (eg repository) with a mockup for unit- or integration-testing
Mocking up "Now" is a common thing for unit testing date sensitive stuff. There are dozens and dozens of articles about doing this, and it's a classic example of why using static methods (eg DateTime.Now) can get you in trouble when it comes time to test.
cheers
Chris Maunder
|
|
|
|
|
I am currently working on my first greenfield project where I am using DI. I personally love it for testing purposes, but when it comes to utility classes THAT DON'T DEPEND ON EXTERNAL RESOURCES, I won't define an interface. Instead I'll just test their public API separately to know that the logic in that class is working as intended. I can then confidently test the code that uses that utility class as an external member.
|
|
|
|
|
Regarding your INowResolver which as stated below it's understandable especially for testing.
There are better ways to handle that.
From ayende.com[^].
public static class SystemTime
{
public static Func<DateTime> Now = () => new SqlDateTime(DateTime.Now).Value;
}
Then in tests
SystemTime.Now = () => new DateTime(2000,1,1);
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
Yeah, it's what I adopted in my own home made project!
I want my home made library of utilities to work out of the box!
I don't want to write lines of (obscure) initialization!
|
|
|
|
|
Super Lloyd wrote: what's your thoughts?
Not sure how often it occurs but it certainly often enough that I have seen people get 'stuck' on an idealization until it bites them - severely.
Probably comes about when they are at the stage where every new idea seems 'fresh and new!' and they want to try all of them out but can only fit a few in. Then someone decides to impose it as a mandate.
This isn't a new trend either. Plenty of examples in the past.
One should use idealizations or even concrete technologies because they are useful now and not because they might be useful at some hazy point in the future. And they should be used with restraint.
|
|
|
|
|
...other than the fact I am posting this from my Wii U.
What do you get when you cross a joke with a rhetorical question?
---
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
---
Do questions with multiple question marks annoy you???
|
|
|
|
|
Unbelievable, but true?! 
|
|
|
|
|
Look -- Ow f**k! -- will you -- OW!! -- be careful with that ****ing sword!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
What do you get when you cross a joke with a rhetorical question?
---
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
---
Do questions with multiple question marks annoy you???
|
|
|
|
|
Don't post to CP while you've got Zelda running.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The only game I have for the Wii U is New Super Mario Bros. U, which is what was (and is) in the system.
What do you get when you cross a joke with a rhetorical question?
---
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
---
Do questions with multiple question marks annoy you???
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
