I'm just getting started with Unity, and am using it with Rhino Mock to allow me to inject mock objects into my code for Unit Testing. It works great. But I have a best practice question when it comes to Unit Testing UI levels and integration testing
top level applications.
I have an object, say a ProductController that implements IProductController, and I build a mock object MockProductController : IProductController that always returns valid Products and know test cases to my View. I am testing my view here, not my controller,
so when I bind the view to my controller, I inject my MockProductController using Unity via altering my app.config. I create this mock controller in a separate assembly, and I need to add a reference to that assembly for my view to see it (as I understand
Once I have completed my testing and am ready to roll out my app, I switch my app.config to point to the real ProductController. No problem.
But do I then roll out my application with my binding to my Mock Assemblies still in place, or do I need to remove the binding and recompile? It seems like I am missing a step here. Where in my solution should I be keeping these MockControllers? What's the
best practice? If I roll out my project with all the Mocks in place, is there a chance someone could flip my config, have it point to one of my mock controllers (i.e. for security) and presto, get around my security layer? Or are these nonsensical concerns?
I do understand how to use something like Rhino Mock in my test harness to test my controller to eliminate other dependencies, but that doesn't bother me because the reference to the Mock classes is made in my test harness project, and that never rolls out.
Usually, we have a separate test project for unit tests and for mocks. This would eliminate the need to add reference to projects that contains the mock objects to your assembly since it doesn't really need to have to. If you want to use the same config
file for your application and test project, you could specify different type mappings for controllers so you won't have to change your config file when you roll out your app. For example, if you have ProductController and MockProductController both inheriting
<type type="IController" mapTo="RealObject.ProductController" name="ProductController" />
<type type="IController" mapTo="Mocks.MockProductController" name="MockProductController" />
With this, you could just resolve the type you need based on the name.
Global Technology & Solutions