Unit Testing with Nunit, Ninject, MVC2 and the ADO.Net Entity Data Model

Question

I'm trying to get my head around using Nunit, Ninject, MVC2 and the ADO.Net Entity Data Model.

Let's say I have have a ProductsController instantiating a SqlProductsRepository class.

public class ProductsRepository : IProductsRepository
{
    public MyDbEntities _context;

    public ProductsRepository()
    {
        _context = new MyDbEntities();
    }

    public IList<Product> GetAllProducts()
    {
        return (from p in _context.Products select p).ToList();
    }
}

public class ProductsController : Controller
{
    public ActionResult ProductsList()
    {
        ProductsRepository r = new ProductsRepository();
        var products = r.GetAllProducts();

        return View(products);
    }
}

I'd like to be able to perform unit testing on ProductsRepository to ensure this is returning the correct data but i'm not sure how to write the Test Class.

Every tutorial/document I've read so far points me to creating a Mock object using IProductsRepository and then injecting and testing the Controller.

This seems, to me, to bypass the concrete implementation.

MyDbEntities comes from an ADO.Net Entity Data Model .edmx

Answer 1

It sounds like you're wanting to create an integration test for ProductsRepository rather than a unit test, since you'd be testing against the database so that you can check it's giving you the right data.

It's when unit testing the Controller that you'd want to mock the ProductsRepository.

In my integration tests for ProductsRepository, I'd be doing the obvious things like

public void TestProductsRepository()
{
  var context = new MyDbEntities();

  // add a new product

  var products = context.GetAllProducts();

  // check products contains new product
}

Answer 2

You're exactly right- mocking the repository does bypass the concrete implementation. That's the point.

Unit testing is not the same thing as functional testing. Your mock object can be set up to return whatever you explicitly define, then you test to ensure that constant inputs from your mock lead to expected results.

Answer 3

With your two classes (ProductsRepository, ProductsController), you should have two sets of tests. One set of tests for each class.

When (unit) testing the ProductsController, you should mock its dependencies (in this case, the IProductsRepository). Bypassing the concrete implementations of the dependencies is the point.

There will be a completely different set of (integration) tests to validate that the ProductsRepository can hit the database and return correct data. In these integration tests you won't mock anything, since what you're testing is the interaction between a real repository with the actual database.