Faking the Turtle Class

By default, faking an instance of a class with Typemock Isolator++ will cause all of that instance's methods to behave like empty methods. Non-void methods will return default values (e.g., 0 for integers, nullptr for pointers).

If a method returns another class, it will return a faked instance of that class.

By faking a class, we override all its methods at runtime, so none of them perform their original functionality unless explicitly configured.

To use Typemock Isolator++ Version 5, include the necessary header file:

#include "Isolator5.h"  
using namespace Typemock;

To fake a new instance, use the Fake.Instance method provided in Isolator5.h:

   auto a = Isolator();  

   Turtle* t = a.Fake.Instance<Turtle>();
   std::cout << t->GetX();

The output will be 0 because GetX() returns the default value (for integers) and has no implementation.

Note: You don’t need to define a derived class or manually set default behaviors for the methods. Typemock handles this automatically at runtime.

How to use it

Since creating fake objects is straightforward, you can directly use them in your unit tests.

Here’s an example using GoogleTest:

#include "Isolator.h"

//setup and teardown support for the test

class MyFirstTestSuite : public ::testing::Test

{};

//the test itself

TEST_F(MyFirstTestSuite, FakeATurtle)

{

   // Arrange

   auto a = Isolator();  

   auto t = a.Fake.Instance<Turtle>()

   // Act

   std::cout << t->GetX();

   // Assert - not done in this example

}

//running our tests

int _tmain(int argc, _TCHAR* argv[])

{

   ::testing::InitGoogleTest(&argc, argv);

   return RUN_ALL_TESTS();

}

Tearing Down and Cleaning Up

Typemock Isolator++ will clean up all fakes once the Isolator object is deleted or goes out of scope. This ensures that expectations, behaviors, and fakes do not persist across tests, preventing conflicts with static methods, global functions, or future objects.

Controlling Fake Behavior

You can configure fake methods to behave as needed using the CallTo method. Here’s an example:

  TEST_F(MyFirstTestSuite, FakeATurtle)

  {

     auto a = Isolator();  

     auto t = a.Fake.Instance<Turtle>()

     a.CallTo(t->GetX()).WillReturn(42);

     int fakeResult = t->GetX();

     ASSERT_EQ(42, fakeResult);

  }

Here we're using the a.CallTo method, which is part of Isolator++ Professional.

When using a.CallTo, you specify the method that you'd like to change, inside the parenthesis. You can then decide what the behavior of future invocations to this method will be.

The different behaviors you can set for methods:

Verifying That Our Turtle Was Called

You can verify that specific methods on a fake object were called using VerifyWasCalled. This is useful for ensuring your code interacts correctly with dependencies.

TEST_F(MyFirstTestSuite, FakeATurtle)

{

   auto a = Isolator();  

   auto t = a.Fake.Instance<Turtle>()

   ClassUnderTest u = new ClassUnderTest(t);

   u.DrawStraightLine(100);

   a.CallTo(t->Forward()).VerifyWasCalled();

}

Here we used another method of Isolator++ Professional - VerifyWasCalled().

This allows us to check, after the fact, that any method on our fake object was indeed called by our class under test.

If t->Forward() was not called on our fake class, then our test will fail.

It's that easy!