Test Double

You might say

When testing an order failure message, use a controllable payment test double that returns “payment rejected” instead of depending on the real payment service every time.

A test double is a controllable object that replaces a real dependency during testing.When an order module requests payment, a double can reliably return success, rejection, or timeout so tests verify how the page handles each. Mock, stub, fake, and spy can be different kinds of test double; not every double is simply a Mock, and it cannot prove a real service is connected.

Know first

Unit Test API

Test DoubleMockStubFakeSpy

How an order module switches between real payment and a controllable double

order.test.jsPayment request inspector

createOrder({ amount: 120 })
payment.charge(120)

POST /payments

endpoint: https://pay.example
amount: 120
response: depends on network/account

Run 1 —Run 2 —Run 3 —

Calling real payment brings network, account, and cost into this order test.

What a double makes testable

Turn hard-to-arrange outcomes into stable input: A real payment service may not reliably produce rejection or timeout on demand. A double returns a specified result for a case, making error display, retry, and logging repeatable.

Match the double to the boundary under test: A double suits testing an order module’s response to rejection; verifying protocol and authentication with the real provider still needs a controlled real connection.

You can say this to an AI Agent

Add a test double that consistently returns payment rejection and verify the page shows a clickable retry entry. Keep one controlled-environment real payment connection check as well; do not substitute the double result for it.

Learn next

1Unit Test→2Integration Test→

Recommended tool

Web fine-tuning tool · Selector Pro

Select page elements for precise AI edits

Click a button, text, or card, note the change, then copy its exact location to AI.

Open Selector Pro website

You need to verify that a rejected payment shows a retry entry, but the real payment sandbox is sometimes unavailable. What is best?

A. Wait until the real payment service happens to rejectB. If the double passes, declare real payment integration verifiedC. Have a payment test double consistently return rejection, then assert the page shows retry