The permits portal calls an external payment provider during renewals. Which test best protects that municipal integration?
Select an answer to reveal the explanation.
Short Explanation
Contract/integration tests are the handshake rehearsal with the payment provider before renewal day. Banner screenshots and brochure load tests never prove the fee charge still works.
Full Explanation
Contract and integration tests verify that callers and providers still agree on request/response shapes, authentication, and error behavior at an API boundary. The permits portal calls an external payment provider during renewals; tests that verify those payment-provider API calls protect the municipal integration citizens depend on when paying fees and receiving receipts.
Visual screenshot diffs of the permits homepage banner catch UI drift on marketing chrome and never exercise authorize, capture, or receipt callbacks. A style guide review for button colors on the fee page is design consistency work, not payment API correctness. Load testing only the static brochure site with no payment calls stresses CDN or static capacity while skipping the renewal payment path entirely—so a brochure that “handles load” can still fail when a resident tries to pay.
Exam caveat: prefer consumer-driven contracts or recorded fixtures plus periodic live sandbox calls so provider changes surface before renewal day; never point destructive charge tests at production payment rails. Operational check: run permits↔payment contract or integration tests in CI on every change that touches renewal or fee code, fail the pipeline if stubs or sandbox calls disagree with the expected contract, and alert owners on provider-side breaking changes.