Recently I was able to get into using the Moq framework for testing code.  For a long time I have wanted to dig in and use mocking as a strategy to test code without all the dependencies.  There is a lot of theory and debate on mocking and I suggest you give some of that a read.  Check out Martin Fowler’s “Mocks aren’t Stubs” or Roy Osherove’s “Art of Unit Testing”

For today’s example I’m going to focus on using Moq for what most would call a Stub.  Let’s take Moq for a spin.

Listing 1 – For this exercise we’ll be working with a Product class.  Products have a name and price and … that’s  it.

    public class Product
    {
        public string Name { get; set; }
        public double Price { get; set; }
    }

Listing 2 – IProductRepository

    public interface IProductRepository
    {
        IEnumerable<Product> GetProducts();
        Product GetProduct(string name);
        int AddProduct(Product product);
    }

Listing 3 – ProductService AddProduct method.  A little business logic to give us something to test.

     public int AddProduct(Product product)
        {
            if (string.IsNullOrEmpty(product.Name))               { throw new ArgumentNullException("product.Name"); }
            if ((product.Price < .10))               { throw new ArgumentException("product.Price"); }

            return _repository.AddProduct(product);
        }

Listing 4 – The tests rely on a _mockRepository initialized as a new Moq.Mock<IProductRepository> in the tests constructor.

private static Moq.Mock<IProductRepository> _repositoryStub;

Listing 5 – The unit tests are where the magic happens.  In our first test, which should succeed, we are initializing our stub to return the number 5 when add product is called with our Candy Bar product.  When this test executes our product service takes in the product, runs the business rules (name cannot be null and price greater than 10 cents) and calls the repository.  In our test the repository being called is actually our stub, so the product never goes to the database.

In the second test you’ll see that we do not initialize stub at all because the test should throw an exception when we try to add a product with a null name.

        [TestMethod()]
        public void AddProduct_ValidProduct_ShouldAddProduct()
        {
            Product newProduct = new Product("Candy Bar", .75);
            _repositoryStub.Setup
                (repo => repo.AddProduct(newProduct)).Returns(5);

            ProductService target =
                new ProductService(_repositoryStub.Object);
            int actual =
                target.AddProduct(newProduct);

            Assert.IsTrue(actual ==5);
        }

        [TestMethod()]
        [ExpectedException(typeof(ArgumentNullException))]
        public void AddProduct_MissingProductName_ShouldThrowArgumentNullException()
        {
            ProductService target = new ProductService
                (_repositoryStub.Object);

            int actual = target.AddProduct
                (new Product { Name = null, Price = 1.5 });
        }

In the constructor for the ProductService you’ll note that _repositoryStub.Object is passed.  In Moq, the object property of the stub is what holds the actual stub you want to use.

This example just scratches the surface of using a mocking framework.  Mocks are great for testing your code in isolation and there are strategies of how you can effectively do that.

In general I began using stubs to test dependencies between a class and interfaces it talks with to get work done.  The service class example above is a common one I’ll use.  We can test the logic of the service class without needing the repository.  This does not leverage the full power of Moq but should be good enough to get you started down the path of mockery.

Enjoy!