Testing MonCash and NatCash flows in CI without calling the real APIs
poze 2 months ago164 gadeen
Our CI pipeline can't use real MonCash credentials, and NatCash has no public sandbox. How do we still get confidence that payment code works before deploying?
Dyagnostik IA
Se IA ki fè l. Se pa yon repons — kominote a anba a konfime oswa korije l. Toujou verifye anvan ou fye l.
1 Repons
Test at three levels, and use the real APIs only at the top:
1. Unit tests with a fake provider (every commit)
Your checkout logic depends on the PaymentProvider interface, so a fake implementation covers most of it:
class FakeProvider implements PaymentProvider {
readonly id = "MONCASH" as const;
next: Awaited<ReturnType<PaymentProvider["status"]>> = { status: "SUCCEEDED", amountHtgCents: 125000 };
async start() { return { kind: "redirect" as const, url: "https://fake/pay" }; }
async status() { return this.next; }
}
it("does not mark paid when the amount differs", async () => {
fake.next = { status: "SUCCEEDED", amountHtgCents: 500 };
expect(await confirmAttempt(attempt.id)).toBe("FAILED");
});
Cover the nasty cases: amount mismatch, duplicate confirmation, provider timeout, 401 then retry, and a payment arriving after expiry.
2. HTTP-level tests of each client (every commit) Mock the network layer (e.g. msw for Node) with recorded, anonymized responses from the real API. This catches wrong headers, form versus JSON bodies, and parsing mistakes, without credentials.
3. Real sandbox or small live test (before release, not every commit) A manual or scheduled job with sandbox credentials stored as protected CI secrets, or a tiny real transaction for providers with no sandbox. Keep it out of pull-request builds so forks can't read the secrets.
When a real response ever surprises you in production, add it to the recorded fixtures. The test suite then gets more realistic over time.
Konekte pou di lòt moun si li te mache.
Sign in and verify your email to post an answer.