Initializing the Test Conditions
Most of my applications make use of the Repository pattern as the portal through which interaction with the data store occurs. Using this approach, I can provide a standard access interface that allows my controller to make one call, and it doesn’t matter if it’s calling into a fake repository or the live repository – the controller logic works the same in either case. The beauty of this approach is it allows me to construct a fake repository in memory, which has several advantages:
- It is extremely fast
- It is always initialized into a known state – I don’t have to write database setup/teardown code
- I don’t even have to have access to the database
So, with that said, my first step in making my test pass is to give it an instance of the fake repository, like so:
I instantiate the fake repository in the Init call, so the repository is alway rebuilt prior to executing the test. That way, if my test makes changes to the repository (i.e. inserts a record, changes a field, etc.) the repository is always returned to a known state before the next test begins.
The next step is to setup my controller to be tested. Here is where the concept of mocking comes into play.
There is a lot of internal plumbing that is setup by IIS during the process of processing an HTTP request. Objects such as HttpContext, cookies, etc. are all wired up before control is passed to your application for further processing. This makes it very difficult to implement unit tests – at least it used to. With the new MVC framework, Microsoft has completely reworked the IIS stack to make it possible to setup the entire environment outside of the web server. There are a number of ways to do this, but the approach I’ve settled on utilizes a project called Rhino Mocks. I have a static class called MockControllerBuilder, which takes care of instantiating my controller with all the surrounding plumbing mocked up and in place. So, for the feature I’m developing right now, my next step is to expand MockControllerBuilder to provide a method for creating my new controller. I do this by adding a new method to the class:
The highlighted red code indicates that I don’t yet have a TransactionJsonController class, so I’ll create that next.
Notice that this controller (as all controllers following this pattern) has two constructors. One is the default constructor (no arguments) used by the MVC framework to instantiate my controller during the processing of a live HTTP request. The other constructor is used by the test framework, and it utilizes a pattern known as Dependency Injection to pass in an instance of my fake repository.
My last step to complete the setup is to use the mock controller builder to create an instance of my controller, like this:
The CreateTransactionJsonController method takes two arguments – an instance of the fake repository, and a profile (or null). By passing in a profile, I am simulating which user is logged in as the controller processes the request. If you look at the fake repository for the instance of the UserProfile with username sbradley@trustecx.com, you will see that this user has been assigned the “Admin” role, so this test will execute as though an Admin user is logged in. By doing this, the unit tests can be constructed to execute under the authorization parameters of various user accounts.
With this done, the test setup is complete. Now I move on to setting up expectations.
