Geeks With Blogs
Moez Mousavi
Unit Testing with VS2008 Team System and Moq
In order to loop around the software development life cycle, you do really have to do the unit testing. Once you get in this stage, you will realise that you need to get your hand dirty with heaps of isolation and refactoring and you wish the whole team had been practicing the Test Driven Programming. It is vital that you test your application and the more dependencies you have in classes, the deeper nightmare for isolation. Possibly in some cases, bad architecture make unit testing almost impossible.
What I gained from playing around might be useful for some developers who are going to get involve with this issue. I am summarising my achievements for you:
The Definition
Unit testing has a completely different meaning from integration testing. You are not going to test interaction between different components of your application; you are going to test small pieces of your application individually, typically testing each method for example. Therefore you need to specify a testing scenario for each unit test.
The traditional way so far, everyone was playing with nUnit. But I guess with Visual Studio 2008 Team System, the life is a little bit easier as you can run the test within the development environment and you don’t need an extra tool. You have code coverage also and it has a sweet code generator which make a typical unit test template for you. In VS2008 Team System you can simply right click on a method name you could get a wizard. The wizard allows you to create unit test for an individual method or property, etc. for all methods inside a class or for the entire of your solution. This is critical factor: Tests must be a part of your source code.
Mocking Framework
Beside of your unit test framework, you will need a mocking framework. Mocking framework will help you to test the interaction between objects. Remember anything which is an Interface, is mockable and you can test it. Moq, TypeMock, RhinoMock , NMock are the most popular ones. TypeMock is the best one but you need to but that. It is free for open source projects only. For someone who loves Lambda expressions probably Moq (hosted in Google) is the best choice. Have a look at to get a free copy and see docs.
Code Management
This is very important that you manage your source code. You will lose maintainability and making the life harder for your co-workers or for future maintenance developer if you have no regulation on your source code structure. I would say having a same structure as your source code for unit testing in a complete separate folder in solution would be the best option. Therefore you have a separate test project for each project in the solution. So you basically map each unit test project to a project within solution structure.
What to test
If the team haven’t follow TDD and you want to just begin writing unit test it might takes ages to write for each individual part of the project specially in enterprise large scale applications. You need to figure out the most important modules such as business rules. Plan ahead and specify what you are going to test. Spending time on unit testing for areas that are not critical such as configurations, loadings, or so on, will increase the time on development and it will cost money. Although it is perfect to test all the available code, but you need to have a realistic view according to the time and budget.
Writing unit test
Making dummy object, stubbing are mocking, isolation and dependency injection are the terms that you need to get yourself familiar with. To be able to write a unit test, you need to have an understanding of what the method is doing and what would be the critical factor to test. For example in what circumstances it throws and exception, for specific input object, what should be expected output and so on. Beside of writing unit test, you might need refactoring the actual code to make them testable.  
At a very high-level, in a typical case, you need to isolate your code from any dependency (i.e. database, a configuration file, etc) and extract an interface. Inject the interface to your methods as a property (rarely as a constructor). Then you would be able to mock that interface and test your method. Mocking is useful to test interaction between objects, counting the times that a particular method has been called.  
At a glance, you will need to record whatever behaviour you need to verify:
Moq, the name space:
using Moq;
Course not a rocket science. Just refrences its Dll. Make sure you have it in your source   control otherwise none of your team members can run your tests or give a hand if writing them.
Setting up a property to test:
   var mockObject = new Mock<IObject>();
   mockObject.SetupProperty(s => s.Id);
When you mock an interface, SetupProperty will give you an on the fly implementation of that interface properties.
Setting Method behaviour:             
    mockObject.Setup(mO => mO.MethodToBeCalled())
 Means you if the MethodToBeCalled, it will return ReturnedObject
Accessing Object properties:
   mockObject.SetupProperty(o => o.Identifier);
   mockObject.Object.Identifier = mockObject2.Object;
Verifying Method call:
   mockObject.Setup(m => m.method(mockObject2.Object));
   mockObject.Verify(m => m.method(mockObject2.Object), Times.Exactly(1));
Making a Callback:
 mockObject.Setup(m => m.Method(mockObject2.Object))
Say you need to perform an action when that method has been called to be able to make another obect to verify against an expected object.
Go get more:
Recent Roy Osherow’s book: The Art of Unit Testing is probably the most completed refrences for learning unit testing. It is covering everything including the methods of isolation, tools, refactoring, design and so on. have a look at for more information
Posted on Monday, March 22, 2010 12:00 AM | Back to top

Copyright © MoezMousavi | Powered by: