Municipal ops needs confidence that a 311 intake change still works with the GIS parcel lookup service. Which testing approach best validates that cross-service behavior?
Select an answer to reveal the explanation.
Short Explanation
Integration tests are the joint drill where 311 intake and GIS actually talk, not each team rehearsing alone. Mocking everything in one module can miss the handshake that breaks on go-live.
Full Explanation
Integration tests exercise multiple components together so real cross-service contracts, data shapes, and failure modes appear. Municipal ops needs confidence that a 311 intake change still works with the GIS parcel lookup service; that is a boundary handshake, not an isolated unit. Integration tests that exercise the 311 intake path against the GIS layer together validate routing, authentication, payload mapping, and lookup results as citizens and dispatchers would experience them.
Unit tests that mock every external call and never leave the intake module are valuable for local logic, but by design they cannot prove the GIS service accepts the new request shape or returns usable parcel data under the changed path. Static linting of CSS theme files in the citizen portal checks presentation consistency and has no bearing on intake-to-GIS behavior. A changelog review meeting with no automated checks may transfer tribal knowledge, yet it produces no executable verification that the cross-service path still works after the change.
Exam caveat: integration tests are slower and more environment-dependent than pure unit tests; scope them to critical municipal boundaries (intake↔GIS) and stabilize test doubles or shared fixtures where full prod GIS is unavailable. Operational check: run the 311–GIS integration suite on the change branch and in the pre-prod environment, verify a sample intake resolves a known parcel, and block promotion if the cross-service assertions fail.