CODEWITHSUNDEEP
c#unit-testingmoles
Ian
Ian

Reputation: 5725

How to test virtual methods using Moles?

How can I test the IsHappy function using Moles?

class SomeClass
{
     protected virtual bool IsHappy(string mood)
     {
          return (mood == "Happy");
     }
}

I tried to test if by using Stub:

SSomeClass stub = new SSomeClass();
stub.CallBase = true;
Assert.IsTrue(stub.IsHappyString("Happy"));

... but the IsHappyString method returns null thus throwing a NullReference exception.

So, how can I test the default implementation of IsHappy method?

Upvotes: 1

Views: 430

Answers (2)

Merlyn Morgan-Graham
Merlyn Morgan-Graham

Reputation: 59121

Stubs and Moles are for isolating a class from any dependencies it has, either environmental dependencies or class dependencies. This class has no dependencies whatsoever, so why are you trying to mole or stub it?

If you want to make sure this base class works properly when people override it, then you'll need to create a test implementation. In that case this is more or less what your test cases should look like:

public SomeClassTestAdapter : SomeClass
{
    public bool GetIsHappy(string mood)
    {
        return IsHappy(mood);
    }
}

[Test]
public void ShouldReturnTrueWhenPassedHappy()
{
    var classUnderTest = new SomeClassTestAdapter();
    bool result = classUnderTest.IsHappy("Happy");
    Assert.IsTrue(result, "Expected result to be true");
}

[Test]
public void ShouldReturnFalseWhenPassedLowerCaseHappy()
{
    var classUnderTest = new SomeClassTestAdapter();
    bool result = classUnderTest.IsHappy("happy");
    Assert.IsFalse(result, "Expected result to be false");
}

[Test]
public void ShouldReturnFalseWhenPassedNull()
{
    var classUnderTest = new SomeClassTestAdapter();
    bool result = classUnderTest.IsHappy(null);
    Assert.IsFalse(result, "Expected result to be false");
}

Etc.

There is no place in this code that stubs or moles should be squeezed in.

If you don't want to create an adapter class for this case, you can use built-in .Net features rather than a big, paid dependency like Moles. Reflections and dynamic let you get access to protected or private members. See this example:

Upvotes: 1

Erik Dietrich
Erik Dietrich

Reputation: 6090

I'd forget about stubs here. Stubs/mocks are for when you want to fake the behavior of a dependency. You'd stub your SomeClass if had SomeClassClient that you wanted to test and it used SomeClass:

    public class Foo
    {
        public virtual int GetFoosInt()
        {
            return 12;
        }
    }
    public class FooClient
    {
        private Foo _foo;

        public FooClient(Foo foo)
        {
            _foo = foo;
        }

        public int AddOneToFoosInt()
        {
            return _foo.GetFoosInt() + 1;
        }
    }

In this example, when testing FooClient, what you want to test is that it returns one more than "GetFoosInt()". You don't actually care what FoosInt is for testing the FooClient. So, you create a Foo stub where you can setup GetFoosInt to return whatever you want.

In your case, testing a protected virtual member, I'd go with this:

[TestClass]
public class SomeClassTest
{
    private class DummySomeClass : SomeClass
    {
        public bool IsHappyWrapper(string mood)
        {
            return IsHappy(mood);
        }
    }

    [TestMethod]
    public void SomeTest()
    {
        var myClass = new DummySomeClass();

        Assert.IsTrue(myClass.IsHappyWrapper("Happy"));
    }
}

This gives you 'direct' access to the protected virtual to test default behavior. Only word of caution is that if you start defining abstract members and adding to SomeClass in general, you'll have to add them to this dummy inheritor as well, adding to testing maintenance overhead.

The purist in me says that you should leave protected members alone and only test them through the public interface. But, that may or may not be practical in your situation, and I don't really see any harm in this approach.

Upvotes: 2

Related Questions