Test Double
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.
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.
createOrder({ amount: 120 })
payment.charge(120)↳Calling real payment brings network, account, and cost into this order test.
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.
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.