Peli De Halleux, a belgian guy now working at Microsoft Research (Redmond) came back in Belgium at the Visug to talk about the project he’s working on. Stubs, Moles and Pex form together a lightweight framework to test .NET applications.

Stubs

Stubs is a stubbing framework solely based on delegates. Various examples can be found here.

Moles

Here’s an example of what you can accomplish with Moles, allowing you to replace any .NET method :

Pex

And here, a diagram showing at a high-level view how Pex works :

Pex is an automated whitebox testing tool for .NET. From your code and parameterized unit tests, test code is automatically generated in C# and test results can be seen in the “input/output table”.

Project-related resources

I could copy-paste the great description of the project off the official website… But I instead recommend to those of you who are interested in this to take a look at the following resources, explaining you what Stubs, Moles and Pex are all about in the details.

The last session of the Visug, held at RealDolmen and presented by Maarten Balliauw concerned Mocking. Here’s an overview of the presentation that was given :

Unit testing

Dependencies

Mocking

Part #1 : Unit testing

Impossible to talk about mocks without mentioning TDD (test driven development). Indeed, mocking is all about unit testing. Unit tests should be :

Self validating (validate themselves against some behaviour or return values)

Fast (you don’t want too long for them to complete)

Focus on a method or functionality (atomicity of testing)

Isolated (from one another)

One of the most famous style of unit testing is the AAA. Below some code example illustrating this :

///<summary>

/// Tests a booking when there is no more rooms

///</summary>

[TestMethod]

publicvoid Restaurant_InsufficiantRoomsTest()

{

// Arrange : prepare your variables and everything needed

Table table = newTable(5);

// Act : execute code

table.Book();

// Assert : check the values or behaviour

Assert.IsFalse(table.IsAvailable);

}

After this introduction, Maarten started some live coding, remembering us that writing unit tests is the first step before coding. You place yourself as client of your future code and see what you’d expect from it. Then, you code it. A little productivity hint : use the Generate Method Stub option from Visual Studio on the methods you haven’t implemented yet (as you code the test first, it won’t compile until you actually implement what you’re testing).

Note : code samples illustrated here are from me, the speaker is thus not responsible for eventual errors they would contain.

Part #2 : Dependencies

Let’s introduce dependencies now. The example that Maarten coded was a bar tender and depending on the weather (web service call), some cheese (sunny) or nuts (rainy) were served with your beer. The problem here is quite evident : how can you test that in the more isolated way possible in order to keep control of your tests ? Indeed, you need to kinda “force” the weather to sunny or rainy to check if your system is implemented properly and delivers the expected behaviour.

To do this, several “stunt double” solutions are offered to you :

Dummy (eg : null, empty list)

Fake (a working implementation)

Stubs (implementation using canned answers)

Mocks (implementation returning expected answers)

Through some live coding again, Maarten showed us how it’s tedious, time consuming to implement fake objects and how unclean it is (classes need to be duplicated for fakes).

Part #3 : Mocking

Mocking frameworks are a convenient interface for setting up fakes/stubs/mocks. They do the job is less code, in AAA style. Some of the more popular mocking frameworks are :

One of the most mature and feature complete mocking framework

Uses Castle remoting for mocking calls

Open source

Free

This is the framework we’re using at work and we are very satisfied of it

Mature and fully featured

Isolates IL generation

Not free

“New kid”, increased popularity

Uses castle remoting

Not feature complete but in development

Open source

Maarten then continued some live coding to illustrate how to use Moq. First, you gotta mock the object you want to fake functionality :

var ws = newMock<IWeatherService>();

Then, declare what you expect from methods :

ws.Setup(s => s.WhatsTheWeather()).Returns("sunny");

Some interesting points (some are general about mocking frameworks) :

Expected exceptions throws can be verified

Callbacks can be made, instead of returning a particular value

Protected members can be mocked

Mocking can be recursive (XML tree generation for example). Prevents you from writing giant stubs

Verify calls to expectations : ws.VerifyAll();

When should I mock ?

External object (web service, DB, …)

Non-deterministic objects (temperature, time, …)

Hard to reproduce situations (simulate a network error, HDD out of space, …)