Updated for 2025 by the Typemock Team
Mocking is a term that comes up often when we talk about unit testing. What does it mean?
The verb “mock” has several definitions, but only one relates to how we use it in software engineering:
a: to imitate (someone or something) closely: mimic
mockingbird was mocking a cardinal —Nelson Hayes
Mocking means replicating the behavior of something. We replace an object with a mock for testing purposes.
Sometimes there is debate over the differences between a mock, a stub, and a fake. We’ll cover all three, with an emphasis on mocking and how you can use it to improve how you design and test your code.
Mocking Defined
Mocking is creating an object that mimics the behavior of another object. It’s a strategy for isolating an object to test it and verify its behavior.
Definitions of mocking differ over whether a mock must verify behavior. However, Fowler calls mocks “objects pre-programmed with expectations which form a specification of the calls they are expected to receive.” Yet Pivotal says they are “self-verifying spies.” Their definitions are good enough for me.
So let’s expand our initial definition:
Mocking is creating an object that mimics another and setting it with expectations about how it will be used.
Modern Example (.NET 8 / MSTest)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[TestMethod] public void SendEmail_Should_Return_True() { var emailService = Isolate.Fake.Instance<IEmailService>(); Isolate.WhenCalled(() => emailService.Send("dev@typemock.com")) .DoInstead((callContext) => { Console.WriteLine($"Pretending to send email to {addr}"); return true; }); var Notifier= new Notifier(emailService); Assert.IsTrue(notifier.Notify("dev@typemock.com")); } |
Modern Example (C++14 / Isolator++)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
TEST(Payments, SendEmail_Should_Return_True) { Isolator a; auto emailService= a.Fake.Instance<IEmailService>(); a.CallTo(emailService.Send(A::Any()) .WillDoInstead([](const std::string& addr){ std::cout << "Pretending to send email to " << addr << std::endl; return true; }; Notifier Notifier; ASSERT_TRUE(notifier.Notify("dev@typemock.com")); } |
“Regular” Unit Testing
Regular unit testing verifies results. A typical example is writing tests for a calculator. A method that adds two integers can be verified by passing it 2 and 2 and checking for 4.
|
1 2 3 |
Assert.AreEqual(4, Add(2,2)); |
A calculator is a unit testing nirvana. If all tests were as simple as a finite set of inputs and a computed output, verifying behavior would be simple. But even in an imaginary functional utopia, objects interact with the outside world. We need a way to keep our unit tests isolated.
Isolation
Isolation is a critical testing concept. When we test an object, it should be separated from other objects and external dependencies.
With the calculator example, this is easy. But it’s more likely that objects will interact with each other and with external dependencies. Isolation is a vital testing goal that often creates the need for mocking.
If we create an object that interacts with a database, making the database a test dependency is not acceptable. We create an object that mimics the database interface.
|
1 2 3 |
var repo = Isolate.Fake.Instance<IUserRepository>(); Isolate.WhenCalled(() => repo.SaveUser()).WillReturn(true); |
But we don’t only isolate from external dependencies. It’s a best practice to confine unit tests as much as possible to one object at a time. When our tests separate components, fixing new problems as they occur is easier.
Imagine moving to a new compiler version and discovering a handful of broken tests. If each test represents a single object, fixing them is simple. If the tests touch three or four objects, repairing the problems is more difficult.
Stubbing and Faking
A stub is an object that mimics another, but with predefined or “canned” responses. We use stubs for tests that rely on an interface to provide one or more calls that return void.
Canned responses can go beyond void, though. Suppose we have an object that inserts single records to a SQL database and the result of a successful insert is always “1,” indicating a single row. We can isolate this object with a simple stub.
A fake is a more sophisticated stub. It implements a subset of the behavior that a production object does, but it’s lighter weight. One example is a fake web service or an in-memory database that replaces a remote version.
This post was written by Eric. Eric Goebelbecker has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!)
Stubs, Fakes & Mocks – 2025 Quick Guide
| Type | What It Does | Typical Use |
|---|---|---|
| Stub | Returns canned data. | “Pretend the API returned OK.” |
| Fake | Lightweight, simplified implementation. | “In-memory DB instead of SQL Server.” |
| Mock | Verifies interactions and expectations. | “Ensure SendEmail() is called once.” |
Use stubs and fakes for static responses, mocks when behavior matters.
Mocking in C++ and .NET Today
With frameworks like Typemock Isolator and Isolator++, developers can test even untestable code:
- Statics & Privates: no refactoring needed
- Legacy C++ modules: isolate without changing headers
- Async & AI-generated code: deterministic mocks ensure repeatable results
👉 Download Typemock Isolator++ Free and start mocking today.
When Not to Mock
Over-mocking hides integration bugs.
Mock your own boundaries but let genuine integrations (like persistence or message buses) prove themselves in separate tests.
FAQ
Creating fake objects that simulate dependencies so code can be tested in isolation.
A stub returns predefined results; a mock checks that expected calls happen.
Yes, Typemock Isolator lets you mock even those restricted constructs.
Yes, Isolator++ provides lambda-based APIs for C++14 and higher.
Conclusion
Mocking isn’t just theory, it’s a practical way to write clean, testable, and agile code.
By isolating dependencies, your tests become faster, more reliable, and easier to maintain.
💡 Next Step:
Explore unit-test patterns for .NET or download Typemock free to start mocking smarter today.
