We are now at the third post of this series and I found out that there are a lot of readers interested in learning TypeMock, which means that series will have to continue!
Last time, we have created some object’s mocks using TypeMock but they were simple Value Objects with nothing or very few business logic in it. This time I want to show you how you can control the behaviors of a mock so that you do not have to control or fake the entire object if you are testing a single method.
Testing a IUnitOfWork
I do not know if you have already created a data layer in your career of software developer; if you did not, you can have a look at one of my tutorials or books about layering an application.
First of all we have a Unit of Work, which allows us to “Save”, “Update” or “Delete” the object we are passing it using a generic signature. The contract for a Unit of Work is represented by the following image:
As you can see we have a simple interface with three methods and we still do not have an implementation for it but we have some expectations that we would like to pre-test using a mock in order to be sure that the next step will be properly handled by TypeMock.
The pre-requisite is that every entity in our domain has some properties inherited by a base class DomainObject; these properties can tell us the ID of the entity, if the entity is new, modified or deleted.
The following object represents the base class for a domain entity.
The 3 properties are of type boolean while the UniqueId is of type Guid, so by default we will have a Guid.Empty value and after we mark dirty or updated the object we should have them populated.
Test the interface
If we test the interface we can start by writing three different expectations like the three following snippets:
And as soon as we run this test it simply fails because of course TypeMock is not able to properly mock the method MarkNew as we did not instruct it on how to do it …
The solution in this case is pretty straightforward, before invoking the MarkNew
In this case we have informed TypeMock that when we will call the method MarkNew
Another way to do that is to use the WillReturn method of TypeMock that can be used, like in this case when we have functions and not void methods.
In the same way we can test that the method may also return an unexpected exception, so we can inform TypeMock to force the mock interface to throw an exception.
This section of type mock is called Controlling method behaviors and you can find a detailed documentation about it at this address:
In the next tutorial we will see how to customize a chain of mockup object and faking the methods so that the IUnitOfWork will be used as a dependency for a Repository class.
If you want you can also download the code of every tutorial at this address on Codeplex:
Encrypted string of the week: IHcKGzESRVs= **
using Blowfish CBC 64bit**