a gotcha with nunit

Was writing a unit test with nunit the other day which went something like :



[Test]
[ExpectedException(typeof(JobExecutionException))]
public void Failure_To_Get_Companies_Sends_Message_And_Logs()
{
   var mockBillingService = new Mock<IBillingService>();
   var mockCompanyService = new Mock<ICompanyService>();
   var mockLogger = new Mock<ILog>();
   var mockJobExectionContext = new Mock<IJobExecutionContext>();

   mockCompanyService.Setup(m => m.CompaniesToBeBilled).Throws(new Exception("problem getting the customers"));
           
   var job = new CustomerBillingJob(mockCompanyService.Object, mockBillingService.Object, mockLogger.Object);
           
    job.Execute(mockJobExectionContext.Object);
    mockLogger.Verify(m => m.Fatal("whoops", It.IsAny<Exception>()), Times.AtLeastOnce());
}

A subtle thing to be wary of is the verify call at the end, we seem to get funny behaviour when we use expected exception in our test and the call to verify seems to get ignored, i'm assuming that all nunit cares about is the fact that the test did throw the expected exception.

I have started rearranging the test so the call to execute is wrapped with a try catch and only handles the exception type you are expecting and does an assertion on that exception being generated.  It is also too easy to put at the top that you expect an exception of type exception too meaning you are not really testing the actual exception type you want to test.

hope that helps.

Autofac DI on action filters

Trying to inject a dependency on an action filter in MVC with autofac the other day, property injection seems to be the order of the day. So here's how to do it:

Here's the filter :

public class MyFilter: FilterAttribute, IAuthorizationFilter
{
       public Dependency MyDependency { get;set;}
}

Autofac registrations:

var builder = new ContainerBuilder();
builder.RegisterFilterProvider();
builder.Register<Dependency>(c => new MyConcreteDependency());
builder.RegisterType<MyFilter>().PropertiesAutowired();

note the RegisterFilterProvider line very important.....

Shazaammm !

stubbing awkward jquery calls with sinon.js

We had an awkward bit of code at work the other day that called a third party control  like so:

function myObject(jsSelector) {
    return $(jsSelector).thirdpartycall({
            propertya: valuea,
            propertyb: valueb
    });
};



so if we want to test myObject, we are now stuck with the unfortunate jquery call inside.  not to worry, sinon.js to the rescue.  first i need to create a fake return object from that javascript call:

 var fakeResult = {
        propertya,
        propertyb,
        thirdpartycall: function (values) {
            this.propertya = values.propertya;
            this.propertyb = values.propertyb;
            return true;
        }
    };

what i do next is to stub jquery, and on using the selector it returns our fake object... yep how cool is that !
make sure when you write your test you wrap it like so (i had some fun with other tests failing after this as I had stubbed jquery permanently !!!)

it("should do something....", sinon.test(function () {

}));

then add the code:

it("should do something....", sinon.test(function () {
    $ = this.stub();
    $.withArgs('#myselector').returns(fakeResult);
}));

           

so now, if we call our object:

myObject('#myselector');

we then check fakeResult and the properties have been set.
Super awesome.