Let me tell you a secret. I don’t like the word “mocking”.
Why?
Because “mocking” refers to the tools we use, rather than what we want to achieve, which is isolation. However, I’ve decided to let this one go a few years back due to public acceptance of the term.
Still, this word has impacted how we’re using mocking (see?) frameworks to this day. You can see that in the APIs. Even in Isolator, we used “Fake” to tell the system to create fake objects, instead of just telling the code-under-test to isolate itself.
Until now.
In Isolator V7 we introduce a new API called Isolate.Fake.Dependencies. Here’s an example for a class under test:
public class UnderTest
{
public int someField;
public UnderTest anotherInstance;
public IInterface iInterface;
public UnderTest(int a, UnderTest nextInstance, IInterface x)
{
this.someField = a;
this.anotherInstance = nextInstance;
this.iInterface = x;
}
}
What’s the simplest case of isolation? Faking the dependencies injected through the constructor, of course! Sure, I can use the regular APIs to create fakes, and initialize the object with them. Or I can use the new API:
[TestMethod]
public void FakeDependencies_FakesAllDependencies()
{
UnderTest underTest = Isolate.Fake.Dependencies<UnderTest>();
Assert.AreEqual(0, underTest.someField);
Assert.AreSame(Isolate.GetFake<iInterface>(underTest), underTest.iInterface);
Assert.AreSame(Isolate.GetFake<UnderTest>(underTest), underTest.anotherInstance);
}
Why would I use the fake dependency? To set behavior. Or verify method behavior. For example:
[TestMethod] public void FakeDependencies_UseWhenCalled()
{
UnderTest underTest = Isolate.Fake.Dependencies<UnderTest>();
Isolate.WhenCalled(() => Isolate.GetFake<IInterface>(underTest).ReturnSomething()).WillReturn(40);
Assert.AreEqual(40, underTest.iInterface.ReturnSomething());
}
In this case I use WhenCalled-WillReturn to specify behavior for the ReturnSomething method.
What happens if I decide to take out either the first or second argument from the constructor? The test still works!
It makes tests more concise and readable, and more robust, because there’s less explicit things to break.
I guess we’re not done with all the “mocking” metaphors. But it’s a step in the right direction.
And it’s part of our new perspective on unit testing.
Want to learn more? Join our webinar about Isolator V7 and be the first to try it out. Join in!
