The Shark Fin: Pex

April 26, 2009 10:02
Imagine: you have a method that needs to be tested.

You right click on it, select "Generate Tests" and a tool generates a suite of tests that cover all code paths. If you later update the original method, you just need to regenerate the tests and the missing coverage is back.

Given that you are still reading,  I will assume that you're ready to take the red pill.

Touching a hot iron: Typemock Isolator

January 11, 2009 21:29

Typemock Isolator costs €449.

Good news: there is a Community Edition that is free[1].When you download the Isolator you get the full Enterprise Edition andafter 21 day the  evaluation licence expires and you're left with thefree features only.

And other mocking frameworks just wither away if you compare the feature sets. (Disclaimer: I'm using Typemock at work.)

Touching a hot iron: Moq

January 4, 2009 19:31

In June 1917, one Russian deputy said that there was no political party willing to demand that the Provisional Government resign and hand power over to it. It was said on a public meeting, and suddenly Vladimir Lenin stood up and called out: "There is such a party!"

In January 2007, Ayende Rahien said that all mocking frameworks, either explicitly or implicitly, use Record/Replay model on mocked objects. It was
stated in Rhino Mocks documentation, and suddenly (er, 11 months later) Daniel Cazzulino stood up and said on his blog: "Well, it's not true anymore".

That's the story.

Touching a hot iron: Rhino Mocks

December 28, 2008 21:28

A while ago, in order to understand Rhino Mocks you had to get into its Record/Replay model: record the expectations first, and then playback the scenario using the mocked objects.

This has been claimed as clumsy and weird by a lot of people (especially those who don’t know much about unit testing). Once you get used to it, it becomes sort of OK, but still it's been considered as a chink in Rhino armor.

In "old"
Rhino Mocks our touch-and-yell test[1] looks like

public void TouchHotIron_Yell()
    var mocks = new MockRepository();
    var hand = mocks.StrictMock<IHand>();
    var mouth = mocks.StrictMock<IMouth>();
    using (mocks.Record()) {
        Expect.Call(() => hand.TouchIron(null)).Constraints(Is.Anything()).Throw(new BurnException());
    using (mocks.Playback()) {
        var brain = new Brain(hand, mouth);
        brain.TouchIron(new Iron { IsHot = true });


Touching a hot iron: NMock2

December 21, 2008 20:17

So here is the method on Brain class we're going to test:

public void TouchIron(Iron iron)
    try { 
    catch(BurnException) {

We need to test the brain in isolation ensuring it yells if a hot iron is passed. In the test, the hand should emulate the hot iron case, and mouth should yell exactly once before the method finishes [1]


Touching a hot iron

December 14, 2008 20:36

So, here we go. Having touched the topic of unit testing, we cannot bypass mocking, can we?

Most of methods use other types to carry on. In order to test something in isolation we need to remove all dependencies, thus the need for fake implementations. Obviously you can write your own fake implementations (so called stubs) but it’s more sort of a dog-walking-on-two-legs solution that is just spooky.

Sooner or later, your subs will end up with logic in them (perhaps even a type hierarchy). Then every stub gets responsible for several similar tests, then production code gets changed and lo and behold, you have some interesting refactoring in hands.

Extirpate hand written stubs. A mocking framework would take all that plumbing upon itself.

Which one to use?

Hmm, good question. A few of the coming posts will be covering the four favorites: NMock2, Rhino Mocks, Typemock Isolator and Moq. To make that review more impartial, the same test scenario will be used everywhere.

And in order to make it more fun this scenario will be taken from real life.

Veni, vidi, fixi. Practical part

December 6, 2008 23:10

The previous part came out a little bit moot – but before you accuse me of selling the sizzle and not the stake, let's look at some code.

Here goes a simple example everybody would easily catch up with. There's a blogger and a reader: the blogger blogs and the reader um, reads.

var blogger = new Blogger();
var reader = new Reader();
var post = reader.GetLatestPost(blogger.Blog);

Unfortunately, in this backstabbing universe the flow could go through a lot of different APIs and the actual code could be less natural. Much less natural.

Veni, vidi, fixi. Theoretical part

November 30, 2008 19:29

Unit testing is a hard sell.

It provides a (sort of) living documentation of the system. It facilitates change, and guards the code from being accidentally mangled, and allows you to refactor at a later date.

a test sometimes can save you a hundred times the cost of creating it.

And at the same time when some guys are procrastinating the unprocrastinable and frantically coding in order to meet their deadlines, a more longsighted guys (like those reading this blog post) prefer writing both code and unit tests and um, deliver less buggy software to happy customers.


That's what they say – but think about it without sensationalising and mawkishness.
It just cannot be that easy, right?