How Would You Mock This?

Hi,

To answer the first question you have to handle a future instance of A - this is done using the Swap.NextInstance() entry point, and will cause the new 'A' to be swapped with the fake instance we can verify against

[TestMethod]
public void GetInstance_SetPropertyOnNewInstance_PropertySetterIsCalled()
{
    // arrange - create a fake A to replace the A instantiation
    var fakeA = Isolate.Fake.Instance<A>();
    Isolate.Swap.NextInstance<A>().With(fakeA);

    // act
    var realA = A.GetInstance();

    //assert - I invented a property to verify on
    Isolate.Verify.WasCalledWithExactArguments(() => { fakeA.Prop = 5; });
}

The second question requires us to verify on a private property getter (BObjects). We do that by using the NonPublic API and inject a fake BCollection that replaces BObjects, and verify against that.

[TestMethod]
public void RegisterB_AddingToCollection_ObjectIsAdded()
{
    // arrange
    var fakeBObjects = Isolate.Fake.Instance<BCollection>();
    Isolate.WhenCalled(() => fakeBObjects.Add(null)).IgnoreCall();

    var fakeA = Isolate.Fake.Instance<A>(Members.CallOriginal);
    Isolate.NonPublic.Property.WhenGetCalled(fakeA, "BObjects").WillReturn(fakeBObjects);

    // act
    var b = new B();
    fakeA.RegisterB(b);

    // assert
    Isolate.Verify.WasCalledWithExactArguments(() => fakeBObjects.Add(b));
}

Please let me know if this helps.

Doron
Typemock Support
[/code]

That does help, thanks.

Another question: if in that static method in A, I pull information from a custom configuration section that does something like:

public static A GetInstance()
{
A a = new A();

var cfg = MyCustomConfigSection.Instance;
//Load config settings into a

return a;
}

Would you recommend mocking the static property Instance (which returns an instance of a custom config component that retrieves it via ConfigurationManager.GetSection), or would you recommend mocking GetInstance and return a custom fake object?

From an ease of use and performance related.

THanks.

Hi Brian,

I wrote about it in the Typemock insiders blog:http://blog.typemock.com/2009/05/quick-tip-how-to-fake-singleton.html

I don't think it matters which of the two you choose as long as they work (faking the instance can only be done before it created).

BTW
In the next version of Typemock Isolator a new feature will be added to enable you to fake all instances (even ones that were already created) which you can use as well.

Dror
Typemock Support

I'm noticing that this:

Isolate.WhenCalled(() => fakeBObjects.Add(null)).IgnoreCall();

If the collection method Add validates the input, this is generating an exception. Is that supposed to happen?

Also, you follow up with, in your test:

Isolate.Verify.WasCalledWithExactArguments(() => fakeBObjects.Add(b));

For me, I get an error that Add wasn't called, and I suspect that's because of the IgnoreCall method.

Has anyone experienced this?

Thanks.

:?: I'm not sure this is so, but is there a chance that fakeBObjects is a standart collection? (i.e. one which is implemented in mscrolib)

If that is the case than you should be aware that at this point Isolator does not deal with types in MSCorlib (other than DateTime see the latest version).

In general, mocking a method means that the real call will not be executed, so you shouldn't see any exception generated by the "Add" real implementation.

Hello,

No, its a custom collection not in MSCoreLib, its my own collection. The mock I'm doing is:

var collectionFake = Isolate.Fake.Instance<PropertyCollection>();
Isolate.SwapNextInstance<PropertyCollection>();
Isolate.WhenCalled(() => collectionFake.Add(new Property("test", this))).IgnoreCall();

var propertyFake = Isolate.Fake.Instance<Property>();
var m = new ModTest();

Isolate.WhenCalled(() => m.AddProperty(null)).IgnoreCall();

m.AddProperty(propertyFake);

Isolate.Verify.WasCalledWithExactArguments(() => collectionFake.Add(propertyFake));

PropertyCollection inherits from a custom colleciton class; that custom collection uses the generic list internally, but it does not inherit directly, but simply defines its own methods. That shouldn't be the issue; besides, I think MSCorLib entities throws exceptions.

But this doesn't work, and as far as I can tell, this is similar to the setup I asked about. Any help as to why verify doesn't verify the add call?

Thanks.

Hi,
What error (or Lior) meant was that even for custom collections, that are not defined in mscorlib, but are based on the collections from mscorlib Isolator has a limitation with them.

The problem is that the Add method, unless you give it a custom implementation, is defined in mscorlib, and that's why setting behavior on it is not possible.

I'm not however understand the problem completely, and would like to take a look at the entire code. Since you have multiple questions around the same code, let's take it offline. I'll write you a separate email.

Thanks,