Mocking replaces an unavailable or unsuitable dependency with a predefined substitute. It lets a UI call an expected API before the real backend is ready, so frontend and backend work can proceed in parallel. section 6.5
Use mocked responses to develop against a stable contract, exercise error responses or edge-case data, and check how a screen handles values that may be difficult to obtain from a live service. Start with hardcoded rows to shape the interface, then replace them with a mocked API call. section 6.5 section 6.4
A WireMock-based workflow keeps the substitute close to the API interaction:
- Define a stub mapping that matches a request method and URL, then returns a status, headers, and body. section 6.5.2
- Store reusable JSON response data in the __files directory and point a mapping's bodyFileName to it. section 6.5.2
- Refresh WireMock mappings after changes, then call the configured endpoint to verify the response. section 6.5.2
Mock recent ACH uploads
A GET request to /api/v1/files can return a JSON array of uploaded ACH files with an id, date, filename, credit total, and debit total. The UI can render and format these values while the real API is still unavailable. section 6.5.2 section 6.4
Choose the substitute according to what the test must prove. Mocking can remove a database dependency, but it is not appropriate when the purpose is to verify that records were actually written to the database. For that case, consider an isolated in-memory database or a managed test PostgreSQL database instead. section 5.2.1
Listing 6.24 ACH response mapping
{
"request": {
"method": "GET", #1
"url": "/api/v1/files" #2
},
"response": {
"status": 200, #3
"headers": { #4
"Content-Type": "application/json" #4
}, #4
"bodyFileName": "ach_files_response.json" #5
}
}
This mapping shows the contract between a GET request for ACH files and a JSON body stored separately as a reusable response file. section 6.5.2
