Browsing all articles from April, 2008

Understanding Mock Objects – Better Design

Author Eli Lopian    Category TDD     Tags

Azam has written a post about Ben Hall’s article “Beginning to Mock Using Rhino Mocks and MbUnit“. The logic in the example is a method that returns an image of the sun in the day and the moon at night. In both Azam’s and Ben Halls examples, the GetImage()method returns the image name

public string GetImage() { int currentHour = DateTime.Now.Hour; if (currentHour > 6 && currentHour < 21) return "sun.jpg"; else return "moon.jpg"; }

Using Interface only Mocking Frameworks will lead to redesigning this in order for the code to be testable and extracting and wrapping ‘DateTime.Now’ to an interface and concrete class:

public interface IDateTime { int GetHour(); } public class DateTimeController : IDateTime { public int GetHour() { return DateTime.Now.Hour; } } public class ImageManagement { public string GetImage(IDateTime time) { int currentHour = time.GetHour(); if (currentHour > 6 && currentHour < 21) return "sun.jpg"; else return "moon.jpg"; } }

Scott Bellware has suggested a better design – and that is to move the ‘is it day or night’ logic from the ImageManagement class to the IDateTime

The calculation of whether it is day or night is an orthogonal concern of the image generation and therefore should be moved out of the GetImage method.

Now our code will look at following:

public interface ITimeService { public bool IsDayTime(DateTime time) } public class ConcreteTimeService : ITimeService { public int IsDayTime(DateTime time) { int currentHour = time.GetHour(); return (currentHour > 6 && currentHour < 21) ; } } public class ImageManagement { public static string GetImage(ITimeService time) { if (time.IsDayTime(DateTime.Now)) return "sun.jpg"; else return "moon.jpg"; } }

The first thing to note is that being forced to use interfaces and Dependency Injection (the first example) did not naturally lead to a good design – there is still a need to think about the design in classical – old fashion – Object Oriented terms.

But if we are thinking about designing in the old fashioned way, here is another approach to reach the same (or better) results: using extension methods, which is a much more natural way of doing this in .NET 3.0+

public static class DateTimeExtensions { public static bool IsDayTime(this DateTime time) { int currentHour = time.GetHour(); return (currentHour > 6 && currentHour < 21) ; } } public class ImageManagement { public static string GetImage() { if (DateTime.Now.IsDayTime()) return "sun.jpg"; else return "moon.jpg"; } }

This makes more sense as we are extending the abilities of DateTime, the code is easy to read and understand. The only problem is how do we test this code.

Well it is simple with Typemock Isolator here is how:

[Test,ClearMocks] public void WhenItIsDayTime_ReturnSunImage() { // pretend it is always day using (RecordExpectations r = RecorderManager.StartRecording()) { r.ExpectAndReturn( DateTime.Now.IsDayTime, true); } Assert.AreEqual("sun.jpg", ImageManagement.GetImage()); }

So here are two points to think about:

  1. You must always think about your design, using IoC and DI does not automatically lead to better designs
  2. If you are already thinking about your design, you might as well have the freedom to develop the design you reached, without limitations of your tools

Why Typemock-Isolator for TDD?

Author Eli Lopian    Category .NET Tests, TDD     Tags

There is a long discussion in the ALT.NET group about TDD and Typemock, it is very interesting and I suggest that you read the thread.

Benefits of TDD

Although the benefits of using TDD are inconclusive, here are some benefits attributed to using TDD:

  • Developers write more tests
  • Tests use the API, so developers can get early feedback on the API design
  • Developers have more Focus as the tasks are divided into small chunks


Why do we need to Mock?

In order to use TDD effectively the tests must

  • Run fast.

  • Run in isolation.

  • Self Contained.

  • Race Safe.

  • Independent.

In order to make sure that we have fast tests, that the tests are self contained and don’t rely on external resources, we need to test our code in isolation from the rest of the system. This is done by mocking out components that are not part of our test, and testing only the unit logic.


TDD and Typemock-Isolator

So where does Typemock-Isolator fit in and how does it compare to other frameworks?

When using TDD with legacy code or 3rd party libraries, the benefits of Typemock-Isolator are well known, so I will not talk about those area’s but about green-field projects.

Developing with Typemock-Isolator, developers will be able to do all the stuff the other frameworks and manual mocks/stubs allow with the addition of being able to mock static methods, private methods and types and a chain of calls (fluent interfaces) in one go (As well as better integration with Visual Studio).

These features make it simpler to divide the code into small chunks – leading to more focus and more tests.

The API’s are still reviewed as tests are written using the API so early feedback of the API’s are part of this process. This is achieved with the freedom to use any internal design of the unit: Extension Methods, Linq, Fluent interfaces, Singletons and Factories.

Other frameworks will force the developer to use DI as an internal pattern. This might be good, but might not be good. It might leave public API’s that where not meant to be public. It will leave the ability to inject an alternative implementation that might ruin the system. It will probably lead to developing extra functionality to support validating and error handling of the injected components. This might be a YAGNI smell that will require extra development and tougher maintenance.  Is DI a silver bullet design pattern?  Or do you want the Freedom to refactor the code to best suit the product – I know that I do, this is what Typemock-Isolator will give: The benefits of TDD with the freedom to refactor your code to any design.


Patent Scam

Author Eli Lopian    Category Uncategorized     Tags

I have just been (nearly) bitten by a few Registration Services  Scams.
Here is how it works:image
After a patent has been received in a patent office, the address of the inventors are published and become public knowledge. There are some (Do Evil) companies that scan these addresses and send very official requests for fee’s for supposed services like “Registration Service Fees”.

These letters and envelopes seem so original that I was about to fall for the scam and pay the fee. The only signs of a scam was the payment method which is different than the normal methods used to pay for Patents.

In the end I called my patent lawyer and asked her what the letter was about. She confirmed that it is a scam.


ASP.NET Unit Testing just got Easier

Author Eli Lopian    Category Product, Release     Tags

There is a lot of talk about unit testing ASP.NET. Artem Smirnov  has managed to build a new tool for writing unit tests for ASP.NET. The tool called Ivonna is available as a beta release.

Ivonna is built on top of the Typemock Isolator framework and facilitates running unit tests in the same process as any other unit test, on the client machine, as well as having a specialized API

To start using, see the Getting Started page on the cool site that Artem built. Artem is kind enough to add a forum for feedback – Please use it.

I am sure that there are other packages that can be built for other component to help simplify unit testing, feel free to contact us and we will help you develop these packages