Skip to main content

4 posts tagged with "moq"

View All Tags

He tasks me; he heaps me.... I will wreak that MOQ upon him.

Enough with the horrific misquotes - this is about Moq and async (that's my slight justification for robbing Herman Melville).

It's pretty straightforward to use Moq to do async testing thanks to it's marvellous ReturnsAsync method. That means it's really easy to test a class that consumes an async API. Below is an example of a class that does just that: (it so happens that this class is a Web API controller but that's pretty irrelevant to be honest)

namespace Proverb.Web.Controllers
{
// ISageService included inline for ease of explanation
public interface ISageService
{
Task<int> DeleteAsync(int id);
}
public class SageController : ApiController
{
ISageService _sageService;
public SageController(ISageService userService)
{
_sageService = userService;
}
public async Task<IHttpActionResult> Delete(int id)
{
int deleteCount = await _sageService.DeleteAsync(id);
if (deleteCount == 0)
return NotFound();
else
return Ok();
}
}
}

To mock the _sageService.DeleteAsync method it's as easy as this:

namespace Proverb.Web.Tests.ASPNet.Controllers
{
[TestClass]
public class SageControllerTests
{
private Mock<ISageService> _sageServiceMock;
private SageController _controller;
[TestInitialize]
public void Initialise()
{
_sageServiceMock = new Mock<ISageService>();
_controller = new SageController(_sageServiceMock.Object);
}
[TestMethod]
public async Task Delete_returns_a_NotFound()
{
_sageServiceMock
.Setup(x => x.DeleteAsync(_sage.Id))
.ReturnsAsync(0); // This makes me *so* happy...
IHttpActionResult result = await _controller.Delete(_sage.Id);
var notFound = result as NotFoundResult;
Assert.IsNotNull(notFound);
_sageServiceMock.Verify(x => x.DeleteAsync(_sage.Id));
}
[TestMethod]
public async Task Delete_returns_an_Ok()
{
_sageServiceMock
.Setup(x => x.DeleteAsync(_sage.Id))
.ReturnsAsync(1); // I'm still excited now!
IHttpActionResult result = await _controller.Delete(_sage.Id);
var ok = result as OkResult;
Assert.IsNotNull(ok);
_sageServiceMock.Verify(x => x.DeleteAsync(_sage.Id));
}
}
}

But wait.... What if there's like... Nothing?#

Nope, I'm not getting into metaphysics. Something more simple. What if the async API you're consuming returns just a Task? Not a Task of int but a simple old humble Task.

So to take our example we're going from this:

public interface ISageService
{
Task<int> DeleteAsync(int id);
}

To this:

public interface ISageService
{
Task DeleteAsync(int id);
}

Your initial thought might be "well that's okay, I'll just lop off the ReturnsAsync statements and I'm home free". That's what I thought anyway.... And I was *WRONG*! A moments thought and you realise that there's still a return type - it's just Task now. What you want to do is something like this:

_sageServiceMock
.Setup(x => x.DeleteAsync(_sage.Id))
.ReturnsAsync(void); // This'll definitely work... Probably

No it won't - void is not a real type and much as you might like it to, this is not going to work.

So right now you're thinking, well Moq probably has my back - it'll have something like ReturnsTask, right? Wrong! It's intentional it turns out - there's a discussion on GitHub about the issue. And in that discussion there's just what we need. We can use Task.Delay or Task.FromResult alongside Moq's good old Returns method and we're home free!

Here's one I made earlier...#

namespace Proverb.Web.Controllers
{
// ISageService again included inline for ease of explanation
public interface ISageService
{
Task DeleteAsync(int id);
}
public class SageController : ApiController
{
ISageService _sageService;
public SageController(ISageService userService)
{
_sageService = userService;
}
public async Task<IHttpActionResult> Delete(int id)
{
await _sageService.DeleteAsync(id);
return Ok();
}
}
}
namespace Proverb.Web.Tests.ASPNet.Controllers
{
[TestClass]
public class SageControllerTests
{
private Mock<ISageService> _sageServiceMock;
private SageController _controller;
readonly Task TaskOfNowt = Task.Delay(0);
// Or you could use this equally valid but slightly more verbose approach:
//readonly Task TaskOfNowt = Task.FromResult<object>(null);
[TestInitialize]
public void Initialise()
{
_sageServiceMock = new Mock<ISageService>();
_controller = new SageController(_sageServiceMock.Object);
}
[TestMethod]
public async Task Delete_returns_an_Ok()
{
_sageServiceMock
.Setup(x => x.DeleteAsync(_sage.Id))
.Returns(TaskOfNowt); // Feels good doesn't it?
IHttpActionResult result = await _controller.Delete(_sage.Id);
var ok = result as OkResult;
Assert.IsNotNull(ok);
_sageServiceMock.Verify(x => x.DeleteAsync(_sage.Id));
}
}
}

Unit testing MVC controllers / Mocking UrlHelper

I have put a name to my pain...#

And it is unit testing ASP.Net MVC controllers.

Well perhaps that's unfair. I have no problem unit testing MVC controllers.... until it comes to making use of the "innards" of MVC. Let me be more specific. This week I had a controller action that I needed to test. It looked a little like this:

Looks fine right? It's an action that takes a simple object as an argument. That's ok. It returns a JsonResult. No worries. The JsonResult consists of an anonymous class. De nada. The anonymous class has one property that is driven by the controllers UrlHelper. Yeah that shouldn't be an issue... Hold your horses sunshine - you're going nowhere!

Getting disillusioned#

Yup, the minute you start pumping in asserts around that UrlHelper driven property you're going to be mighty disappointed. What, you didn't expect the result to be null? Damn shame.

Despite articles on MSDN about how the intention is for MVC to be deliberately testable the sad fact of the matter is that there is a yawning hole around the testing support for controllers in ASP.Net MVC. Whenever you try to test something that makes use of controller "gubbins" you have serious problems. And unfortunately I didn't find anyone out there who could offer the whole solution.

After what I can best describe as a day of pain I found a way to scratch my particular itch. I found a way to write unit tests for controllers that made use of UrlHelper. As a bonus I managed to include the unit testing of Routes and Areas (well kind of) too.

MvcMockControllers updated#

This solution is heavily based on the work of Scott Hanselman who wrote and blogged about MvcMockHelpers back in 2008. Essentially I've taken this and tweaked it so I could achieve my ends. My version of MvcMockHelpers looks a little like this:

What I want to test#

I want to be able to unit test the controller Edit method I mentioned earlier. This method calls the Action method on the controllers Url member (which is, in turn, a UrlHelper) to generate a URL for passing pack to the client. The URL generated should fit with the routing mechanism I have set up. In this case the route we expect a URL for was mapped by the following area registration:

Enough of the waffle - show me a unit test#

Now to the meat; here's a unit test which demonstrates how this is used:

Let's go through this unit test and breakdown what's happening:

  1. Arrange
  2. Act
  3. Assert

The most interesting thing you'll note is the controller's UrlHelper is now generating a URL as we might have hoped. The URL is generated making use of our routing, yay! Finally we're also managing to unit test a route registered by our area.

Unit Testing and Entity Framework: The Filth and the Fury

Just recently I've noticed that there appears to be something of a controversy around Unit Testing and Entity Framework. I first came across it as I was Googling around for useful posts on using MOQ in conjunction with EF. I've started to notice the topic more and more and as I have mixed feelings on the subject (that is to say I don't have a settled opinion) I thought I'd write about this and see if I came to any kind of conclusion...

The Setup#

It started as I was working on a new project. We were using ASP.NET MVC 3 and Entity Framework with DbContext as our persistence layer. Rather than crowbarring the tests in afterwards the intention was to write tests to support the ongoing development. Not quite test driven development but certainly test supported development. (Let's not get into the internecine conflict as to whether this is black belt testable code or not - it isn't but he who pays the piper etc.) Oh and we were planning to use MOQ as our mocking library.

It was the first time I'd used DbContext rather than ObjectContext and so I thought I'd do a little research on how people were using DbContext with regards to testability. I had expected to find that there was some kind of consensus and an advised way forwards. I didn't get that at all. Instead I found a number of conflicting opinions.

Using the Repository / Unit of Work Patterns#

One thread of advice that came out was that people advised using the Repository / Unit of Work patterns as wrappers when it came to making testable code. This is kind of interesting in itself as to the best of my understanding ObjectSet / ObjectContext and DbSet / DbContext are both in themselves implementations of the Repository / Unit of Work patterns. So the advice was to build a Repository / Unit of Work pattern to wrap an existing Repository / Unit of Work pattern.

Not as mad as it sounds. The reason for the extra abstraction is that ObjectContext / DbContext in the raw are not MOQ-able.

Or maybe I'm wrong, maybe you can MOQ DbContext?#

No you can't. Well that's not true. You can and it's documented here but there's a "but". You need to be using Entity Frameworks Code First approach; actually coding up your DbContext yourself. Before I'd got on board the project had already begun and we were already some way down the road of using the Database First approach. So this didn't seem to be a go-er really.

The best article I found on testability and Entity Framework was this one by K. Scott Allen which essentially detailed how you could implement the Repository / Unit of Work patterns on top of ObjectSet / ObjectContext. In the end I adapted this to do the same thing sat on top of DbSet / DbContext instead.

With this in place I had me my testable code. I was quite happy with this as it seemed quite intelligible. My new approach looked similar to the existing DbSet / DbContext code and so there wasn't a great deal of re-writing to do. Sorted, right?

Here come the nagging doubts...#

I did wonder, given that I found a number of articles about applying the Repository / Unit of Work patterns on top of ObjectSet / ObjectContext that there didn't seem to be many examples to do the same for DbSet / DbContext. (I did find a few examples of this but none that felt satisfactory to me for a variety of reasons.) This puzzled me.

I also started to notice that a 1 man war was being waged against the approach I was using by Ladislav Mrnka. Here are a couple of examples of his crusade:

Ladislav is quite strongly of the opinion that wrapping DbSet / DbContext (and I presume ObjectSet / ObjectContext too) in a further Repository / Unit of Work is an antipattern. To quote him: "The reason why I don’t like it is leaky abstraction in Linq-to-entities queries ... In your test you have Linq-to-Objects which is superset of Linq-to-entities and only subset of queries written in L2O is translatable to L2E". It's worth looking at Jon Skeets explanation of "leaky abstractions" which he did for TekPub.

As much as I didn't want to admit it - I have come to the conclusion Ladislav probably has a point for a number of reasons:

1. Just because it compiles and passes unit tests don't imagine that means it works...#

Unfortunately, a LINQ query that looks right, compiles and has passing unit tests written for it doesn't necessarily work. You can take a query that fails when executed against Entity Framework and come up with test data that will pass that unit test. As Ladislav rightly points out: LINQ-to-Objects != LINQ-to-Entities.

So in this case unit tests of this sort don't provide you with any security. What you need are **integration

** tests. Tests that run against an instance of the database and demonstrate that LINQ will actually translate queries / operations into valid SQL.

2. Complex queries#

You can write some pretty complex LINQ queries if you want. This is made particularly easy if you're using comprehension syntax. Whilst these queries may be simple to write it can be uphill work to generate test data to satisfy this. So much so that at times it can feel you've made a rod for your own back using this approach.

3. Lazy Loading#

By default Entity Framework employs lazy loading. This a useful approach which reduces the amount of data that is transported. Sometimes this approach forces you to specify up front if you require a particular entity through use of Include statements. This again doesn't lend itself to testing particularly well.

Where does this leave us?#

Having considered all of the above for a while and tried out various different approaches I think I'm coming to the conclusion that Ladislav is probably right. Implementing the Repository / Unit of Work patterns on top of ObjectSet / ObjectContext or DbSet / DbContext doesn't seem a worthwhile effort in the end.

So what's a better idea? I think that in the name of simplicity you might as well have a simple class which wraps all of your Entity Framework code. This class could implement an interface and hence be straightforwardly MOQ-able (or alternatively all methods could be virtual and you could forego the interface). Along with this you should have integration tests in place which test the execution of the actual Entity Framework code against a test database.

Now I should say this approach is not necessarily my final opinion. It seems sensible and practical. I think it is likely to simplify the tests that are written around a project. It will certainly be more reliable than just having unit tests in place.

In terms of the project I'm working on at the moment we're kind of doing this in a halfway house sense. That is to say, we're still using our Repository / Unit of Work wrappers for DbSet / DbContext but where things move away from simple operations we're adding extra methods to our Unit of Work class or Repository classes which wrap this functionality and then testing it using our integration tests.

I'm open to the possibility that my opinion may be modified further. And I'd be very interested to know what other people think on the subject.

Update#

It turns out that I'm not alone in thinking about this issue and indeed others have expressed this rather better than me - take a look at Jimmy Bogard's post for an example: http://lostechies.com/jimmybogard/2012/09/20/limiting-your-abstractions/.

Update 2#

I've also recently watched the following Pluralsight course by Julie Lerman: http://pluralsight.com/training/Courses/TableOfContents/efarchitecture#efarchitecture-m3-archrepo. In this course Julie talks about different implementations of the Repository and Unit of Work patterns in conjunction with Entity Framework. Julie is in favour of using this approach but in this module she elaborates on different "flavours" of these patterns that you might want to use for different reasons (bounded contexts / reference contexts etc). She makes a compelling case and helpfully she is open enough to say that this a point of contention in the community. At the end of watching this I think I felt happy that our "halfway house" approach seems to fit and seems to work. More than anything else Julie made clear that there isn't one definitively "true" approach. Rather many different but similar approaches for achieving the same goal. Good stuff Julie!

A Simple Technique for Initialising Properties with Internal Setters for Unit Testing

I was recently working with my colleagues on refactoring a legacy application. We didn't have an immense amount of time available for this but the plan was to try and improve what was there as much as possible. In its initial state the application had no unit tests in place at all and so the plan was to refactor the code base in such a way as to make testing it a realistic proposition. To that end the domain layer was being heavily adjusted and the GUI was being migrated from WebForms to MVC 3. The intention was to build up a pretty solid collection of unit tests. However, as we were working on this we realised we had a problem with properties on our models with internal setters...

Background#

The entities of the project in question used an approach which would store pertinent bits of normalised data for read-only purposes in related entities. I've re-read that sentence and realise it's as clear as mud. Here is an example to clarify:

public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Address { get; set; }
public DateTime DateOfBirth { get; set; }
/* Other fascinating properties... */
}
public class Order
{
public int Id { get; set; }
public string ProductOrdered { get; set; }
public string OrderedById { get; set; }
public string OrderedByFirstName { get; internal set; }
public string OrderedByLastName { get; internal set; }
}

In the example above you have 2 types of entity: Person and Order. The Order entity makes use of the the Id, FirstName and LastName properties of the Person entity in the properties OrderedById, OrderedByFirstName and OrderedByLastName. For persistence (ie saving to the database) purposes the only necessary Person property is OrderedById identity. OrderedByFirstName and OrderedByLastName are just "nice to haves" - essentially present to make implementing the GUI more straightforward.

To express this behaviour / intention in the object model the setters for OrderedByFirstName and OrderedByLastName are marked as internal. The implication of this is that properties like this can only be initialised within the current assembly - or any explicitly associated "friend" assemblies. In practice this meant that internally set properties were only populated when an object was read in from the database. It wasn't possible to set these properties in other assemblies which meant less code was written (a good thing

) - after all, why set a property when you don't need to?

Background explanation over. It may still be a little unclear but I hope you get the gist.

What's our problem?#

I was writing unit tests for the controllers in our main web application and was having problems with my arrangements. I was mocking the database calls in my controllers much in the manner that you might expect:

// Arrange
var orderDb = new Mock<IOrderDb>();
orderDb
.Setup(x => x.GetOrder(It.IsAny<int>()))
.Returns(new Order{
Id = 123,
ProductOrdered = "Packet of coffee",
OrderedById = 987456,
OrderedByFirstName = "John",
OrderedByLastName = "Reilly"
});
}

All looks fine doesn't it? It's not. Because OrderedByFirstName and OrderedByLastName have internal setters we are unable

to initialise them from within the context of our test project. So what to do?

We toyed with 3 approaches and since each has merits I thought it worth going through each of them:

  1. To the MOQumentation Batman!: http://code.google.com/p/moq/wiki/QuickStart! Looking at the MOQ documentation it states the following:

    Mocking internal types of another project: add the following assembly attributes (typically to the AssemblyInfo.cs) to the project containing the internal types:

    // This assembly is the default dynamic assembly generated Castle DynamicProxy,
    // used by Moq. Paste in a single line.
    [assembly:InternalsVisibleTo("DynamicProxyGenAssembly2,PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]
    [assembly: InternalsVisibleTo("The.NameSpace.Of.Your.Unit.Test")] //I'd hope it was shorter than that...

    This looked to be exactly what we needed and in most situations it would make sense to go with this. Unfortunately for us there was a gotcha. Certain core shared parts of our application platform were GAC'd. A requirement for GAC-ing an assembly is that it is signed.

    The upshot of this was that if we wanted to use the InternalsVisibleTo approach then we would need to sign our web application test project. We weren't particularly averse to that and initially did so without much thought. It was then we remembered that every assembly referenced by a signed assembly must also be signed as well. We didn't really want to sign our main web application purely for testing purposes. We could and if there weren't viable alternatives we well might have. But it just seemed like the wrong reason to be taking that decision. Like using a sledgehammer to crack a nut.

  2. The next approach we took was using mock objects. Instead of using our objects straight we would mock them as below:

    //Create mock and set internal properties
    var orderMock = new Mock<Order>();
    orderMock.SetupGet(x => x.OrderedByFirstName).Returns("John");
    orderMock.SetupGet(x => x.OrderedByLastName).Returns("Reilly");
    //Set up standard properties
    orderMock.SetupAllProperties();
    var orderStub = orderMock.Object;
    orderStub.Id = 123;
    orderStub.ProductOrdered = "Packet of coffee";
    orderStub.OrderedById = 987456;

    Now this approach worked fine but had a couple of snags:

    • As you can see it's pretty verbose and much less clear to read than it was previously.

    • It required that we add the virtual keyword to all our internally set properties like so:

      public class Order
      {
      // ....
      public virtual string OrderedByFirstName { get; internal set; }
      public virtual string OrderedByLastName { get; internal set; }
      // ...
      }
    • Our standard constructor already initialised the value of our internally set properties. So adding virtual to the internally set properties generated ReSharper warnings aplenty about virtual properties being initialised in the constructor. Fair enough.

    Because of the snags it still felt like we were in nutcracking territory...

  3. ... and this took us to the approach that we ended up adopting: a special mocking constructor for each class we wanted to test, for example: ```cs ///

    /// Mocking constructor used to initialise internal properties /// public Order(string orderedByFirstName = null, string orderedByLastName = null) : this() { OrderedByFirstName = orderedByFirstName; OrderedByLastName = orderedByLastName; }

    Thanks to the ever lovely [Named and Optional Arguments](<http://msdn.microsoft.com/en-us/library/dd264739.aspx>) feature of C# combined with [Object Initializers](<http://msdn.microsoft.com/en-us/library/bb397680.aspx>) it meant it was possible to write quite expressive, succinct code using this approach; for example:
    ```cs
    var order = new Order(
    orderedByFirstName: "John",
    orderedByLastName: "Reilly"
    )
    {
    Id = 123,
    ProductOrdered = "Packet of coffee",
    OrderedById = 987456
    };

    Here we're calling the mocking constructor to set the internally set properties and subsequently initialising the other properties using the object initialiser mechanism.

    Implementing these custom constructors wasn't a massive piece of work and so we ended up settling on this technique for initialising internal properties.