November 8, 2011

Recently I attended a seminar by Roy Osherove about good practices in unit tests.

Roy stressed hard that there should be no logic in the unit tests, I totally agree with that. He goes and on an explains that the logic in the unit tests can be symptom of two things

Missing Logic in your domain Model

If you have to write a lot of logic for a unit tests then it means that some one in their web application(or some other client application) will be writing the same logic.

This essentially means that if this logic changes at one place it will be have to be changed on the other places also, which will seriously hurt the maintainability of the unit tests. I like to consider as another client to your domain logic layer, more logic you have in business logic layers, less you will need to replicate in different clients.

A test that should have been divided into two or more tests

This is simple cohesion principal a test(or a method) should do only do one thing and do it well.

Who is testing my tests

There was an interesting question by Roy caught my attention “who is testing your tests?”. Your tests should not have logic as there is not one testing your unit tests.

I would like to believe that in most of the cases the unit tests and the code are in equilibrium state. So if one end is faulty the whole balance will be compromised. Unit tests check your code and the code checks your unit tests. In most of the situations when there is a bug in my unit test it will be fail as now it will not be doing what is expected of it. So I do not fully agree with this reason none the less I totally agree with the concept itself.

September 4, 2011

Some days back I was having a chat with a friend of mine regarding unit test and DI, we were going though his code and we started discussion on some of the service locators in his services code which I thought should also have been injected(DI or IoC), but he disagreed as he thought these locators are generic enough so they do not need to be injected or wrapped or abstracted. In the similar lines one my team members created a static configuration class in the core and was using it to access the configuration for the application, which started the discussion on how far your should go when it comes to dependency injection.

To answer this question I tried to look into an extreme example in my code and how it paid off in the end.

Recently in a project I wrote some services which were saving certain statistics about a website. An Asp.Net MVC application was calling my application controller service to store the statistics. These statistics are saved in the context of a Date. In this scenario I can easily use a DateTime.UtcNow.Date inside my service for the Date and be done with it. The challenge comes when you have to write unit tests for this situation. We need to generate some sample data to test the system properly. Considering this situation I created an interface to inject the Date.

public interface IClock { DateTime Get(); }

In my unit test project I created an implementation of this such that I can set the Date externally.

Now I created a method in my unit test project

internal class DateProvider : IClock { public DateTime CurrentDate;

public DateProvider() { }

public DateTime Get() { return CurrentDate; } }

I wrote a some code to generate random statistics and recorded the data created in the memory so that I can test it later on. Here is how the code looks like

so now I am able to generate a random date in the past and I am able to record in memory the data created so that I can test that correct data was created by my services or not.

As you can see that in this situation injecting a trivial thing like date has saved the day in terms of unit testing. So I believe that you should to inject every possible dependency as a convention, it may come handy at some time….

August 17, 2011

The basic principal of writing a unit tests is that when you do a transaction you know the “expected” result and then you compare with the actual result that was generated, and if these results match you have a passed unit test.

It is always interesting to write unit tests for Database services. Usually the problem that comes to mind is how to exactly predict the state of the database at the time when unit tests are running, so that the unit tests know what to expect. Some people may argue that you can mock out all the database functionality (mock the repositories), this idea may be very applicable in some scenarios but I usually do not go this way because of two reasons,

It seems like to much work

Our applications are mostly data driven applications so there is not much to test anyway other than database transactions.

One way of knowing the exact state of the database can be to initialize(create) the database every time the unit tests are run. Once the database is created we might want to insert some initial data which is required for the unit tests.

I have been using Entity Framework Code first in my recent projects. Entity Framework provides you a very good way of achieving the two objectives I have mentioned in the previous paragraph.

EF provides a concept of Database initializers, these are implementations which define the strategy of how (rather when) the database will be created using our model (if you are a bit lost then I recommend to watch Code First Development with Entity Framework). These implementations implement an Interface called IDatabaseInitializer. There are some pre-backed strategies for database creation are provided with the EF. The one we are interested here is DropCreateDatabaseAlways. The name says it all, when using this strategy a database will be created every time code is executed(unit tests are run). To use the Initializers all you need to do is to write the following code before your unit tests are executed

(Make sure you are using a local database server(SQL Express), things can really stressed if you are using a shared development server .)

So now our database is created every time unit tests are run, now we need to create some data each time the database is created. For this you can inherit the DropCreateDatabaseAlways class and override a method called Seed. using this method you add the initial records you want to create every time database is created.

context.SaveChanges(); base.Seed(context); } } The seed method is called just after the database is created by the the framework. Now all you need to do it to tell the framework to use your Database Initializer, and that you will do by modifying the code I wrote above.