tags:

views:

1335

answers:

2

Im very new top mocking frameworks, but I have decided to take a look at Moq. It is my understanding that I can test that a method call will occur if I call a higher level method i.e.

public abstract class SomeClass()
{    
    public void SomeMehod()
    {
           SomeOtherMethod();
    }
    internal abstract void SomeOtherMethod();
}

Basically, all I want to test is that if I call SomeMethod() than I expect that SomeOtherMethod() will be called.

I am right in thinking this is the sort of test is available in a mocking framework?

+3  A: 

You can see if a method in something you have mocked has been called by using Verify, e.g.:

static void Main(string[] args)
{
        Mock<ITest> mock = new Mock<ITest>();
        mock.Expect(m => m.MethodToCheckIfCalled())
            .Verifiable();

        ClassBeingTested testedClass = new ClassBeingTested();
        testedClass.WorkMethod(mock.Object);

        mock.Verify(m => m.MethodToCheckIfCalled());
}
class ClassBeingTested
{
    public void WorkMethod(ITest test)
    {
        //test.MethodToCheckIfCalled();
    }
}
public interface ITest
{
    void MethodToCheckIfCalled();
}

If the line is left commented it will throw a MockException when you call Verify. If it is uncommented it will pass.

Paul
This is the correct answer. You must understand something, however. You CANNNOT mock a method/property that is not abstract or virtual (obviously, all interface methods and properties can be mocked).
Will
Perfect, thankyo
Owen
-1: The .Expect(...).Verifiable() is redundant in this code. Using AAA the verify you have is just right. .Verifiable is for usage with .Verify() i,.e. the no arg version. See http://stackoverflow.com/questions/980554/what-is-the-purpose-of-verifiable-in-moq/1728496#1728496
Ruben Bartelink
A: 

@Paul: I'm also new to mocking, but looking at your implementation I can't stop wonder that what you are doing is adapt the code to allow mocking, breaking code logic. My point is, and taking Owen's class as example, if we have another public (or internal) method in our class, why should we move that logic to an interface? This is forcing the class consumer to create additional code. For example: let assume we have a class that has two methods: One for returning a list of countries and another that, based on a suplied countrycode, searches the countries list for the correct description:

public virtual string GetCountry(string code)
{
    IOrderedEnumerable<KeyValuePair<string, string>> countries = GetCountries();
    var result = countries.Where(x => x.Key.Equals(code)).Single();
    return result.Value;
}

if I understood correctly, I would have to change this method signature to receive an additional parameter so I could correctly mock this class method's:

public virtual string GetCountry(ICountriesList list, string code)
{
    IOrderedEnumerable<KeyValuePair<string, string>> countries = list.GetCountries();
    var result = countries.Where(x => x.Key.Equals(code)).Single();
    return result.Value;
}

Or is it another way? Thanks.

Bruno Shine