chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes
As described in the comments below this Blog post?

http://blog.typemock.com/2008/07/preview-and-questions-on-next-isolator.html

We will support Base Calls using OnBase

MyTest.WhenCalled(() => fake.Log()).OnBase().WillReturn("555");
asked by Christian.Merat (2.9k points)

7 Answers

0 votes
Hi,

OnBase() is not planned at the moment. Since it's the second time we're asked for this feature we'll discuss it again here and reconsider adding it to the Isolator backlog.

Can you describe the scenario you're trying to test? I'll try help writing a unit test for it.

Regards,
Elisha,
Typemock Support
answered by Elisha (12k points)
0 votes
Here's what I'm trying to test.

public class BaseClass
{

    public virtual void Something(object arg)
    {
        // do something
    }


}

public class NewClass : BaseClass
{
    public override void Something(object arg)
    {
        base.Something(arg);

        if (condition)
        {
            SomethingElse(arg);
        }
    }

    public void SomethingElse(object arg)
    {
         // do something else
    }
}


I want to test that "SomethingElse" is only being called when "condition" is true. The problem is that I cannot override behavior for "base.Something(arg)" to ignore base behavior. Ex: Isolator.WhenCalled(() => obj.Something(arg)).OnBase().IgnoreCall();
answered by Christian.Merat (2.9k points)
0 votes
Hi,

The reflective API (old generation of Isolator API) supports faking base class method.

For example:
public class BaseClass
{
    public virtual void Something(object arg)
    {
        throw new Exception("Base not supposed to be called");
    }
}

public class NewClass : BaseClass
{
    public bool WasSomethingElseCalled;

    public override void Something(object arg)
    {
        base.Something(arg);
        SomethingElse(arg);
    }

    public void SomethingElse(object arg)
    {
        WasSomethingElseCalled = true;
    }
}

[TestMethod]
public void ReflectiveAPIExampleForIgnoringBaseCalls()
{
    Mock mock = MockManager.Mock(typeof (NewClass));
    mock.CallBase.ExpectCall("Something");
    
    var underTest = new NewClass();
    underTest.Something(null);

    Assert.IsTrue(underTest.WasSomethingElseCalled);
}


If we'll add support to base calls faking to Isolator we'll let you know.

Regards,
Elisha,
Typemock Support
answered by Elisha (12k points)
0 votes
It supports calling it and expecting a call, but it doesn't support Ignoring the call (or having a DoInstead block), which is problematic since I don't actually want the base to be executed.

For now, I can work around by faking and swapping the other classes used in the base call, but it's a good deal more work than just putting "IgnoreCall".
answered by Christian.Merat (2.9k points)
0 votes
Christian,

In the old reflective API, putting in ExpectAlways() is the same as ignoring the call. It will also not cause the test to fail if the call is not made. You can also use ExpectAndReturn() using a DynamicReturnValue delegate as return value to enforce dynamic behavior. You can read more about this here: https://www.typemock.com/Docs/UserGuide/ ... Value.html.

Please let me know if this works out for you.

Doron
Typemock Support
answered by doron (17.2k points)
0 votes
I managed to perform the test using the reflective API, however there's something that doesn't quite work properly:

mock.AlwaysReturn("Something", new DynamicReturnValue((parameters, context) =>
{
    return MockManager.CONTINUE_WITH_METHOD;
}));
mock.CallBase.AlwaysReturn("Something", new DynamicReturnValue((parameters, context) =>
{
    // do nothing, this is just to block the call to the base Something method.
    return null;
}));


In this case, all calls to base.Something will still be handled by the first DynamicReturnValue. This may be by design (and I've managed to work around it) but it still can be somewhat limiting. You can't mock both the method behavior and the base method behavior.
answered by Christian.Merat (2.9k points)
0 votes
Hi Christian,

The behavior you see is not by design :(
I added that to our bug list.
answered by ohad (35.4k points)
...