Mock vs stub comparison in Postman - Trade-offs & Expert Analysis

Overview - Mock vs stub comparison

What is it?

Mocks and stubs are tools used in software testing to simulate parts of a system that are not yet built or are difficult to use during tests. A stub provides fixed responses to calls made during the test, while a mock can also check if certain calls were made and how. Both help testers isolate the part of the system they want to test by replacing other parts with controlled behavior.

Why it matters

Without mocks and stubs, testing parts of a system that depend on other parts would be slow, unreliable, or impossible if those parts are incomplete or unavailable. They allow developers to test early and often, catching bugs sooner and making software more reliable. Without them, testing would be harder, slower, and less effective, leading to more bugs in the final product.

Where it fits

Before learning mocks and stubs, you should understand basic software testing concepts like unit testing and integration testing. After this, you can learn about test doubles in general, including spies and fakes, and then explore automated testing frameworks that support these tools.

Mental Model

Core Idea

Mocks and stubs are pretend parts of a system used during testing to control and check interactions without relying on real components.

Think of it like...

Imagine you are rehearsing a play but some actors are missing. A stub is like a stand-in who always says the same lines without changing, while a mock is a stand-in who not only says lines but also remembers if they were called on stage and how they acted.

┌───────────────┐       ┌───────────────┐
│   Test Code   │──────▶│     Stub      │
│               │       │ (fixed reply) │
└───────────────┘       └───────────────┘
         │                      ▲
         │                      │
         │                      │
         ▼                      │
┌───────────────┐       ┌───────────────┐
│   Test Code   │──────▶│     Mock      │
│               │       │ (checks calls)│
└───────────────┘       └───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Test Doubles Basics

Concept: Introduce the idea of test doubles as substitutes for real components during testing.

In software testing, sometimes the real parts of a system are unavailable or hard to use. Test doubles are fake versions of these parts that help tests run smoothly. They include stubs, mocks, fakes, and spies, each with different roles.

Result

Learners understand why and when to replace real components with test doubles.

Knowing that test doubles exist helps you test parts of software independently, making testing easier and more reliable.

2

Foundation

What is a Stub in Testing?

Concept: Explain stubs as simple test doubles that return fixed responses.

A stub is a fake component that returns preset answers to calls during a test. It does not check how it was used; it just provides data so the test can continue. For example, a stub API might always return the same user data regardless of input.

Result

Learners can identify and create stubs to simulate dependencies with fixed behavior.

Understanding stubs helps isolate the tested code by controlling external data and behavior.

3

Intermediate

What is a Mock in Testing?

Concept: Introduce mocks as test doubles that can verify interactions.

A mock is like a stub but smarter. It not only returns data but also records how it was called. Tests can then check if the mock was used correctly, such as verifying if a function was called with the right arguments or the expected number of times.

Result

Learners can create mocks that both simulate behavior and verify usage.

Knowing mocks lets you test not just outcomes but also how your code interacts with other parts.

4

Intermediate

Comparing Stubs and Mocks Side-by-Side

🤔Before reading on: Do you think mocks and stubs serve the same purpose or have different roles? Commit to your answer.

Concept: Highlight the key differences and when to use each.

Stubs provide fixed responses without checking usage. Mocks provide responses and verify how they were called. Use stubs when you only need to supply data. Use mocks when you want to check interactions. For example, in Postman, a stub might return a fixed API response, while a mock can also check if the request was made as expected.

Result

Learners clearly distinguish when to use stubs versus mocks.

Understanding the difference prevents misuse and improves test accuracy and clarity.

5

Advanced

Using Mocks and Stubs in Postman

🤔Before reading on: Can Postman mocks verify request details or only return responses? Commit to your answer.

Concept: Show how Postman supports mocks and stubs in API testing.

In Postman, you can create mock servers that return predefined responses (stubs). Postman mocks can also log requests, allowing you to verify if the API was called correctly. This helps test API clients without needing the real backend. You can write tests in Postman to assert that the mock received expected requests.

Result

Learners know how to implement and use mocks and stubs practically in Postman.

Knowing Postman's capabilities helps create reliable API tests early in development.

6

Expert

Pitfalls and Best Practices with Mocks and Stubs

🤔Before reading on: Do you think overusing mocks can make tests fragile or more reliable? Commit to your answer.

Concept: Discuss common mistakes and how to avoid them for maintainable tests.

Overusing mocks can make tests tightly coupled to implementation details, causing frequent breaks when code changes. Stubs that return unrealistic data can hide bugs. Best practice is to mock or stub only external dependencies, keep data realistic, and avoid verifying internal implementation. In Postman, keep mocks simple and use tests to check meaningful interactions.

Result

Learners understand how to write robust tests using mocks and stubs.

Knowing these pitfalls helps maintain test quality and reduces false confidence.

Under the Hood

Mocks and stubs work by intercepting calls that would go to real components and instead returning predefined data or recording call details. In Postman, mock servers listen for API requests and respond with stored examples. Internally, mocks keep track of request metadata to allow verification, while stubs simply return static responses without tracking.

Why designed this way?

They were designed to enable testing in isolation, allowing developers to test parts of a system without waiting for all components to be ready. The separation between stubs and mocks reflects the need to either just supply data or also verify interactions, balancing simplicity and control.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Test Code     │──────▶│ Mock/Stub     │──────▶│ Real Component│
│ (calls API)   │       │ (intercepts)  │       │ (if available)│
└───────────────┘       └───────────────┘       └───────────────┘
         │                     ▲
         │                     │
         └─────────────Logs calls or returns fixed data

Myth Busters - 3 Common Misconceptions

Quick: Do you think mocks always return dynamic data? Commit to yes or no.

Common Belief: Mocks always generate dynamic or realistic data.

Reality: Mocks can return fixed or dynamic data depending on how they are set up; they mainly focus on verifying interactions, not data realism.

Why it matters: Assuming mocks always produce realistic data can lead to tests that pass but fail in real scenarios due to unrealistic mock responses.

Quick: Do you think stubs can verify how they were called? Commit to yes or no.

Common Belief: Stubs can check if they were called correctly during tests.

Reality: Stubs only provide fixed responses and do not verify call details; that is the role of mocks.

Why it matters: Confusing stubs with mocks can cause missed bugs because interaction verification is skipped.

Quick: Do you think using too many mocks makes tests more reliable? Commit to yes or no.

Common Belief: More mocks always make tests more reliable by isolating code.

Reality: Excessive mocking can make tests fragile and tightly coupled to implementation, causing frequent breaks on code changes.

Why it matters: Over-mocking leads to high maintenance costs and false confidence in test results.

Expert Zone

1

Mocks can be stateful, tracking sequences of calls, which helps test complex interactions but adds complexity.

2

In Postman, mocks can be combined with scripting to simulate different scenarios dynamically, not just static responses.

3

Choosing between mocks and stubs depends on whether you need to verify behavior or just supply data, which affects test design and maintenance.

When NOT to use

Mocks and stubs are not suitable for end-to-end tests where real components must interact fully. Instead, use integration or system testing with real services. Also, avoid mocks when testing pure functions that do not depend on external components.

Production Patterns

In real projects, developers use stubs early to simulate APIs under development, then add mocks to verify client behavior. Postman mocks are often used in API contract testing and to enable frontend teams to work before backend completion.

Connections

Dependency Injection

Mocks and stubs are often used with dependency injection to replace real components during testing.

Understanding dependency injection helps you see how mocks and stubs fit into flexible, testable code design.

Behavior-Driven Development (BDD)

Mocks support BDD by verifying interactions that reflect expected behavior.

Knowing how mocks verify calls helps implement BDD scenarios that focus on behavior, not just outputs.

Theater Rehearsal Process

Both involve stand-ins and role-playing to prepare for the real performance.

Recognizing this connection highlights the importance of controlled practice environments to ensure smooth final execution.

Common Pitfalls

#1 Using stubs when interaction verification is needed.

Wrong approach:

In Postman, creating a mock server but only checking response data without verifying if the request was made correctly.

Correct approach:

Use Postman mocks with test scripts that assert the request method, headers, and body to verify interactions.

Root cause:

Confusing stubs with mocks and not understanding the need to verify how dependencies are used.

#2 Over-mocking internal implementation details.

Wrong approach:

Mocking every internal function call inside the component under test, leading to fragile tests.

Correct approach:

Mock only external dependencies and test internal logic with real code to keep tests stable.

Root cause:

Misunderstanding the scope of mocking and trying to control too much of the system.

#3 Using unrealistic stub data that hides bugs.

Wrong approach:

Stubs returning always successful responses even when errors should be tested.

Correct approach:

Design stubs to return varied realistic data, including error cases, to test different scenarios.

Root cause:

Underestimating the importance of realistic test data for uncovering edge cases.

Key Takeaways

Mocks and stubs are essential tools to simulate parts of a system during testing, enabling isolated and reliable tests.

Stubs provide fixed responses without verifying usage, while mocks also check how they are called.

Using mocks and stubs correctly helps catch bugs early and speeds up development by allowing testing before all components are ready.

Overusing mocks or using unrealistic stubs can make tests fragile or misleading, so balance and realistic data are key.

In Postman, mocks and stubs help test APIs effectively by simulating backend behavior and verifying client interactions.