Question

Just imagine that my asp.net mvc Controller method could have this code:

testplanService.AddTestplan(testplan,template,release);

which calls the below implemented service method:

public TestplanService
{

public void AddTestplan(Testplan testplan, Template template, Release release)
        {
           testplan.CreatedAt = DateTime.Now;
           testplan.UserId = WindowsIdentity.GetCurrent().Name;
           testplan.Name = release.Name + " " + template.Name + " " + testplan.UserId + " " + testplan.CreatedAt;

           _provider.AddTestplan(testplan, template, release);                             
        }

}

How can I test the CreatedAt, UserId and the Name property in the ASSERT when I do not know
the values inside this method?

Yes I know I could pass all 3 values inside the testplan object which is anyway passed to the service method, BUT a Controller class in mvc should not have these 3 lines of logic.

So what would you do?

Answer 1

Just imagine that my asp.net mvc Controller method could have this
code:

testplanService.AddTestplan(testplan,template,release);

I don’t want to imagine anything like that. The correct way is that your controller works with abstractions, not actual implementations. So instead of depending on an actual service implementation, this testplanService variable that you are using in your controller will be a simple interface or an abstract class that will be injected into the constructor of your controller.

Now in your unit test you could actually mock this interface and test your controller in isolation.

Now let’s consider the actual implementation of the service:

public void AddTestplan(Testplan testplan, Template template, Release release)
{
    testplan.CreatedAt = DateTime.Now;
    testplan.UserId = WindowsIdentity.GetCurrent().Name;
    testplan.Name = release.Name + " " + template.Name + " " + testplan.UserId + " " + testplan.CreatedAt;
    _provider.AddTestplan(testplan, template, release);                             
}

There are a couple of issues with this method. First of all it depends on non-deterministic data such as DateTime.Now which are difficult to unit test. Martin Fowler has a nice article about non-determinism in unit tests. It also depends on the current WindowsIdentity. All that’s hard to unit test because your method depends on actual implementations instead of working with abstractions.

So you will have to abstract those notions behind providers that you can mock in your unit test. Make sure all your components are weakly coupled between them. You will find it much easier to work with them in isolation.

---

UPDATE:

As requested in the comments section here’s an example of how to abstract datetime retrieval:

Consider the following class:

public class WeekendTester
{
    public bool IsWeekendSoon()
    {
        return (int)DateTime.Now.DayOfWeek > 3;
    }
}

It’s obvious that unit testing IsWeekendSoon is very difficult as it will depend on the day your unit test is run.

So in order to break the non-determinism in this method you could do the following:

public class WeekendTester
{
    private readonly Func<DateTime> _dateTimeProvider;
    public WeekendTester(Func<DateTime> dateTimeProvider)
    {
        _dateTimeProvider = dateTimeProvider;
    }

    public bool IsWeekendSoon()
    {
        return (int)_dateTimeProvider().DayOfWeek > 3;
    }
}

Now all that you need is to configure your favorite DI framework to inject () => DateTime.Now into the constructor of this object and inside your unit test you can easily mock it:

[TestMethod]
public void Weekend_Is_Still_Far_Away_From_The_28_th_Of_February_2012()
{
    // arrange
    Func<DateTime> providerMock = () => new DateTime(2012, 2, 28);
    var sut = new WeekendTester(providerMock);

    // act
    var actual = sut.IsWeekendSoon();

    // assert
    Assert.IsFalse(actual);
}

You can see how in this example we are able to force the method work with whatever date we want it to in the unit test in order to verify the correct behavior of the method.