CI tests for a municipal permit service call a third-party payment gateway and sometimes charge cards or fail when the vendor is down. How should integration tests be written?
Select an answer to reveal the explanation.
Short Explanation
CI should not swipe real cards to prove a permit fee path. Mock the payment gateway so tests stay fast, safe, and vendor-independent. Live prod credentials and real PANs in fixtures are how audits get exciting for the wrong reasons.
Full Explanation
Integration tests for a municipal permit service should mock the external payment gateway so CI does not depend on vendor uptime or charge real cards. Domain 3 testing expects isolation from flaky third parties while still verifying the application's handling of approval, decline, and error responses. Crafted mock successes and failures keep county CI deterministic and ethically free of accidental charges against production merchant credentials.
Always calling the live payment gateway with production merchant credentials from CI fails because it can charge cards, incur fees, leak credentials into CI logs, and fail whenever the vendor is down. Disabling all integration tests and relying only on manual clicks in production fails conceptually by discovering payment bugs on citizens. Storing real citizen card numbers in the test suite fixtures for realism fails as a serious privacy and PCI-minded violation.
Exam caveat: mocks must cover decline, timeout, and idempotency paths—not only happy-path approvals—or production still surprises during peak permit season. Operational check: run CI with the gateway mocked, assert the app records the correct permit payment states, and reserve a rare controlled vendor-sandbox test outside the default PR gate if needed.