[GTest] (4) Example - virtual method

Short answer:

• If you want to use Google Mock (or any runtime polymorphism) to replace the real Tier with a mock at test time, you do need the methods to be virtual. That’s how the mock can override the real behavior.
• If you do not need to substitute different implementations at runtime (no polymorphism needed), then you don’t strictly need virtual methods.

Below is a more detailed breakdown:

---

1. Why virtual methods are typically required

In C++:

1. Runtime Polymorphism:
   When you have a base class pointer (like Tier* tier) and store an object of a derived class (BasicTier, MockTier, etc.), the virtual keyword on methods is what enables the correct derived method to be called at runtime.
2. Google Mock:
   Google Mock relies on creating a mock class derived from your interface/abstract base class and overriding its virtual methods with gMock’s MOCK_METHOD. If the methods in the base class are not marked virtual, the derived mock class can’t properly override them.

Without virtual methods, you’d get static binding instead of dynamic dispatch. That means the calls to tier->someMethod() would always call the base class version (or produce a compile/link error if no definition is provided), rather than any overridden method in a derived class.

---

2. What if you don’t use virtual methods?

If you do not need polymorphism—i.e., you never plan to have different implementations (including mocks) behind the same interface at runtime—then you can skip virtual methods. For example:

• You have a Tier concrete class with no inheritance or mocking needs, so you just define Tier without virtual.
• In your tests, you never substitute a different version (mock or otherwise).

However, as soon as you need to inject a different behavior in place of Tier—like a mock or a specialized class—you need dynamic polymorphism so the correct derived methods are called. That requires virtual.

---

3. Alternative approaches to mocking without virtual methods

If you’d like to avoid virtual methods entirely, you could consider:

1. Template-based injection (compile-time polymorphism).
   • You might pass the “tier” as a template parameter, e.g., Car<TierImplementation>. Then for production you use Car<BasicTier> and for tests you use Car<MockTier>. This technique avoids virtual, but it can complicate your code and is less common when using gMock.
2. Link-time substitution or preprocessor-based mocks.
   • These are more awkward in C++ and not typically recommended; you’d do something like separate “mock” definitions in test builds vs. production builds. But you lose the fine-grained control and expressiveness that Google Mock provides.

In practice, most C++ teams prefer straightforward runtime polymorphism (interfaces with virtual methods) when a class truly needs different implementations or test doubles (mocks/fakes) at runtime.

---

4. Conclusion

• To do standard mocking with Google Mock and a base/derived design, you need virtual methods in your base class (the interface).
• If you don’t require polymorphism or test doubles, you can omit virtual. But then you can’t easily replace the real implementation with a mock at test time.

So, in most common unit testing scenarios involving mocking, marking methods as virtual in your interface (like Tier) is the standard and recommended approach.