Comments on: Understanding Mock Objects – Better Design

By: Eli Lopian

Eli Lopian — Mon, 05 May 2008 18:19:15 +0000

Thanks ulu,
You are correct, This stresses the point that there is a need to *think* about the API, and not let the tests lead to wrong or over designed software.
In any case we might find it better to encapsulate the fact that GetImage() changes the image according to the time, and we might not want our client to pass a boolean time, we might in the future want to change the image every hour, or depending on geo-location. These are implementation details that should be encapsulated.

By: ulu

ulu — Mon, 05 May 2008 08:44:56 +0000

Hi,

Recently I discovered that perhaps dependency injection is a bit overused. Sometimes it’s quite frustrating: you want to use someone else’s class, and you have to figure out a lot of dependencies only to find out that the 6th in the chain is internal or something.

Anyway, you could have two completely independent classes here with two methods:
bool DayService.IsDayTime(this DateTime time)
and
string ImageProvider.GetImage(bool gimmeTheDayImage)
Both classes can be tested without any mocks, and both can be reused in other places without any knowledge of each other, or any related interfaces.

We still need a high-level API though, a class that glues these classes. How do we test it? We write an integration test. And that’s where TypeMock can really help, since we can’t use DI at this level. Too bad we can’t mock mscorlib..

By: Eli Lopian

Eli Lopian — Wed, 30 Apr 2008 11:30:28 +0000

Thanks Chris

Neil, Typemock is used on many projects that have GOOD – Well thought designs, albeit not bound to using ONLY the IoC Pattern.
These designs are a result of hard *thinking* in OO terms. Just because a developer doesn’t have the correct tools to verify that his code is working, doesn’t make his design bad or lacking.

About your design point: It is a valid point for this example, but not for the concept that I am trying to convey.
See, accepting DateTime as an argument is defying the encapsulation principal and perhaps the YAGNI principal too.
Why should the client care about how we get the correct image? Why should he know that we are even asking for the time?

By: Neil Mosafi

Neil Mosafi — Wed, 30 Apr 2008 10:34:32 +0000

Hmm, I am not sure about this, and I don’t think using TypeMock should be encouraged for this sort of solution. I am seeing TypeMock used on more and more projects to hide bad/lack of design, when it was really built to enable testing of legacy components which cannot be refactored.

Still… I believe the whole assumption that a mock is required for any of this is incorrect. Why do you need to mock in the first place? If your ImageManagement.GetImage function simply accepts a DateTime as a dependency then you ahve removed the dependency on DateTime.Now. Then you can test your method passing in a DateTime where the hour is less than 6pm and one where it is greater than 6pm.

Why assume that your consumer will always be interested in determining whether it is currently day or night? For example, he may wish to perform a lookup on historical data. You are making your service less useful by forcing the dependency on DateTime.Now.

By: Chris Holmes

Chris Holmes — Tue, 29 Apr 2008 23:26:02 +0000

Brilliant post Eli. I’m a big believer in IoC, etc., helping lead the way toward a better design. But you’re post showed that no matter how many tools and techniques you employ, you still have to actively *think* about design. The tools and techniques will only get us so far.