BDD with MSpec and Rhino Auto Mocks (part 2)

November 19, 2009 · 3 minute read · Tags: Agile | BDD | MSpecs | RhinoMocks

In part 1, we looked at setting up MSpec and writing our first specifications.

Now we get on to the all important implementation stage.

We ended up with these basic specifications by the end of part 1.

  1. using Machine.Specifications;
  2.  
  3. namespace MSpecExample.Tests.Controllers
  4. {
  5.     [Subject("Product Search")]
  6.     public class when_product_search_page_requested
  7.     {
  8.         It should_return_product_search_page;
  9.     }
  10.  
  11.     [Subject("Product Search")]
  12.     public class when_asked_for_products_matching_search_term
  13.     {
  14.         It should_retrieve_a_list_of_products_with_titles_containing_the_search_term;
  15.         It should_return_the_list_of_products_to_the_user;
  16.     }
  17.  
  18.     [Subject("Product Search")]
  19.     public class when_empty_search_term_entered
  20.     {
  21.         It should_return_an_error_message;
  22.     }
  23. }

Lets start by implementing the first one (when product search page requested).

  1. [Subject("Product Search")]
  2. public class when_product_search_page_requested
  3. {
  4.     static ProductController _controller;
  5.  
  6.     Establish context =
  7.         () => {
  8.             _controller = new ProductController();
  9.         };
  10.  
  11.     It should_return_product_search_page;
  12. }

On first glance, the wacky syntax here might put people off. However, once you start writing these tests you tend to see past it to the specs and the tests themselves.

We start by establishing the context for our test, what we need for this test to actually run. In this case it’s the product controller that we’re testing, and so it makes sense to instantiate the product controller and assign it to a field for use within our tests.

Next we need to actually do something, perform the action which we are testing. In this case we’re talking about the user visiting the “product search page” so I will set up the test to call an action on the product controller called Search.

  1. [Subject("Product Search")]
  2. public class when_product_search_page_requested
  3. {
  4.     static ProductController _controller;
  5.     static ActionResult _result;
  6.  
  7.     Establish context =
  8.         () => { _controller = new ProductController(); };
  9.  
  10.     Because of =
  11.         () => { _result = _controller.Search(); };
  12.  
  13.     It should_return_product_search_page;
  14. }

Note how we have created a Because statement. In BDD terms this is the behaviour we are testing. As with the controller I store the result of calling this action in a field so we can use it elsewhere in the test.

At this point I should point out that in the spirit of TDD, I am only doing enough at this point to make this compile. So our Product Controller currently looks like this.

  1. public class ProductController : Controller
  2. {
  3.     public ActionResult Search()
  4.     {
  5.         throw new NotImplementedException();
  6.     }
  7. }

Jumping back to our test, lets test that the behaviour under test (search) does what we expect.

  1. [Subject("Product Search")]
  2. public class when_product_search_page_requested
  3. {
  4.     static ProductController _controller;
  5.     static ActionResult _result;
  6.  
  7.     Establish context =
  8.         () => { _controller = new ProductController(); };
  9.  
  10.     Because of =
  11.         () => { _result = _controller.Search(); };
  12.  
  13.     It should_return_product_search_page =
  14.         () => { _result.is_a_view_and().ViewName.ShouldEqual("Search"); };
  15. }

Using an extension method (thank you James Broome and JP Boodhoo) we can simultaneously check that our result is a view and also get a typed reference to the result (as a ViewResult).

  1. public static class TestExtensions
  2. {
  3.     public static ViewResult is_a_view_and(this ActionResult result)
  4.     {
  5.         return result as ViewResult;
  6.     }
  7. }

Now we make the test pass.

  1. public class ProductController : Controller
  2. {
  3.     public ActionResult Search()
  4.     {
  5.         return View("Search");
  6.     }
  7. }

Finally we run MSpec and marvel at the results 😉

image

We still have several not implemented specs, but the one we have implemented now appears as a simple line of text. If there were any problems with the test (if it failed) we would see a red error message by the failing specification.

In part 3 we’ll look at more complex controller actions and introduce Rhino Auto Mocker.

Join the Practical ASP.NET Newsletter

Ship better Blazor apps, faster. One practical tip every Tuesday.

I respect your email privacy. Unsubscribe with one click.

    Next up

    BDD with MSpec and Rhino Auto Mocks (part 3)
    BDD with MSpec and Rhino Auto Mocks (part 1)