Mocking frameworks – dream feature

Eli Lopian    .NET Tests, Product, TDD    

There are some developers SHOUTING, that mocking static and  non-virtual methods is a big No-No. Roy, is calling them dogmatic.

Come on guys, the most requested feature from Rhino.Mocks is the ability to mock non-virtual and static members, and Oren has even implemented these when possible (MarshalByRef Objects). I am sure that if it was easy, Daniel would do so too.

In other languages where objects can be swapped without Dependency Injection, there is no-one, calling these features – Bad Practice, just the opposite. They are called ‘Power features’, because that is what they are.

You might prefer to sweat and spend a lot of your time figuring out how to make your code testable, and you might find it easier in your company to introduce a free tool, but please, don’t call a tool that gives you lot of pain,  forces you to use DI (even if you don’t really need it) and to spend time creating utterly useless wrappers – a feature!

Interesting Unit Testing Survay

Eli Lopian    TDD    

According to a Telerik Survey  (brought to me by Avi Kaye) Unit Testing is still not mainstream.

I am not sure how many people voted, and although the result might surprise some of you, these results confirm what I think about the implementation of automated unit tests.

Unit testing is still quite difficult and there is a need for better tools to help with the pain.

Typemock Isolator 4.2.4 is available

Eli Lopian    Product, Release    

Typemock Isolator 4.2.4 is available for download.
This is a patch release with many bug fixes.

• “Invalid Operation Exception” when working with NHybernate and XML serialization was fixed.
• Complex LINQ queries are now mocked correctly.
• Manual assembly loading does not cause an exception. AssemblyResolve event fires correctly.
• RepeatAlways now works correctly following WhenArgumentsMatch.
• Returning values of types that inherit from generic type now work correctly.
• GetMocks return the correct mocks for abstract classes and interfaces.
• Following undeploy Typemock Isolator remains registered.
• Methods up to 30 parameters can now be mocked.

Get the juicy development information here

Ruby Style Mocking in .NET

Eli Lopian    .NET Tests    

I had a great discussion with a college about the difficulties of understanding the technical parts of the automated Mocking frameworks.

The one point that takes some time to grasp is the fact that  methods are written within the test that are not actually called, but are stubs/mocks that will be called at a later time. This is true to all frameworks. He then suggested that having the ability to swap one type with another would help in understanding the flow of the test. So I whipped together some code to do just that.

Using this code it is possible to swap one type with another. The two types must have the same methods, but the swapping type doesn’t need to have all the methods of the original type.

Here is an example:

public class OriginalClass
{
    public int ReturnOne()
    {
        return 1;
    }
    public static int StaticReturnOne()
    {
        return 1;
    }
}

Static Method Swapping

Suppose we want to fake the static methods of the OriginalClass, we simply write a new class.

public class FakeClass
{
    public static int StaticReturnOne()
    {
        return 2;
    }
}

Note: apart from the names of the methods the two classes are not related.

Here is how we fake the calls,

• We Swap the OriginalClass with the FakeClass by: Swap.StaticCalls()
• All static calls to OriginalClass methods that exist in the FakeClass are diverted to the FakeClass.
• We Unswap the types at the end of the test by Swap.Rollback()

[TestMethod]
public void SwapStatic_CallsFake()
{
    Swap.StaticCalls<OriginalClass, FakeClass>();
    Assert.AreEqual(2, OriginalClass.StaticReturnOne());
    Swap.Rollback();
}

Instance Swapping

We can do the same with instances, we can create a new FakeClass and swap the instances.

public class FakeClass
{
    public int ReturnOne()
    {
        return 2;
    }
}

Note: again, apart from the names of the methods the two classes are not related, but they both might implement the same interface or base class and thus support refactoring.

Here is how we fake the calls,

• We Swap the next new OriginalClass with the FakeClass by Swap.NextNew().
• All calls to that OriginalClass method which exist in the FakeClass are diverted to the FakeClass.

[TestMethod]
public void SwapInstance_CallsFake()
{
    Swap.NextNew<OriginalClass, FakeClass>();
    OriginalClass swappedInstance = new OriginalClass();
    Assert.AreEqual(2, swappedInstance.ReturnOne());
}

Missing Methods

At this stage the missing methods of the swapped type can have 2 behaviors:

• Call the original class (Default or UndefinedMethods.CallOriginal)
• Do nothing and Return a default value (UndefinedMethods.Ignore)

This is set in the swap statements.

Downloads

• Source along with tests
• Binaries for the project