×
Get in touch

Get in touch with Binary

Binary Studio website uses cookies to enhance your browsing experience. By continuing to use our site, you agree to our Privacy Policy and use of cookies.

Learn more more arrow
Agree
Binary Studio 19.03.2010

Unit testing facilitation in .NET application development: MOQ Framework


This article concentrates on mocking framework Moq as great tool for unit testing. It overviews various facilities of Moq on concrete functionality samples and unit tests written with the help of this mocking framework.

.NET development: Using Moq Framework for unit testing

Explanation of “What is Moq” you can find here. I will just give it in short.

Moq is mocking library for .NET. It takes full advantage of .NET 3.5 (i.e. Linq expression trees) and C# 3.0 features (i.e. lambda expressions) that make it the most productive, type-safe and refactoring-friendly mocking library available. And it supports mocking interfaces as well as classes. It is extremely simple and straightforward, and doesn't require any prior knowledge or experience with mocking concepts.

Start of works with MOQ

In order to begin using Moq you will require moq.dll (you can download it from this indirect link). After you download it and reference to your testing project you can start using it. Quick start samples you can find here and I think they would provide you with more than enough information to begin testing.

But from my side I want to give you few advices and deeper level samples which I got when tried to resolve various problems during development and testing. Anyway I should give some easy samples, so that my next article would be consistent.

Let’s consider that we have next User model and manager interfaces (IUserManager and INotificationManager) which interact with such model.

public class User { public int Id { get; set; } public string Name { get; set; } public string Area { get; set; } } public interface

And UserService which serves some logic using both manager interfaces:

I would strongly recommend use interfaces so this will make code more flexible and implementation independent but using mocking you may get deeper into internals of logic you test. This does not mean that Moq could not mock concrete class method. For such case you just need to make public method modifier virtual. Anyway testing of systems built with use of IoC/DI patterns and loose object coupling with Moq look and work very organically.

Enough with talking and continue with testing. Let’s start with testing method of UserService:

public User LoadAndPreset(string name, string newName, string area) { //searching by old name var user = _userManager

As you can see we are searching for user by name and area and then updating name of found user to specified new value. So best (and one for this situation) candidate to be mocked is IUserManager.Find because in the real it would access to database or other storage where users are and it would be complicated and/or time consuming to execute/prepare in the test over real data access or so.

Before start testing let’s initialize mock objects:

[TestFixture] public class UserServiceTests { private Mock<IUserManager> _userManagerMock = new Mock<IUserManager>();

The following test checks correctness of service method execution:

[Test] public void LoadAndPresetTest() { //this user object we wish method Find to return var user = new User()

So what we defined with Moq? Actually we said that we would expect IUserManager.Find to be called with parameters “old value” and “area” and if method will be called with such parameters it should return object of type User defined by us.

Note that parameters with which you call method should be equal to parameters you passed into method setup.

Following sample shows such situation:

var user1 = new User(); var user2 = new User(); _userManagerMock.Setup(m => m.Delete(user1)) .Returns(true); _service.Del

Mocked method will not be called because user1 is not equal to user2 and by default mocking behavior (Mock.Behavior==Loose) mocked IUserManager.Delete will return false (which is actual default(T)). You may set Mock.Behavior to Strict if you want to be notified with exception about not set up method was called. But for the case of loose mock behavior we may check if our mocked method was called by Mock.VerifyAll (actually it will check for each setup) so if we put _userManagerMock.VerifyAll() after service method call we will get exception saying that not all setup methods called.

For the cases when you cannot specify exactly same parameter value to method setup you may use one of:

It.Is<T>(Expression<Predicate<T>>), It.IsAny<T>(T), It.IsRegex<T>(string), It.IsInRange<T>(T,T). _userManagerMock.Setup(m =

And back again to loose coupling. Let’s look on next situation: