Discovery - Mock server improvements - Happy Paths, Errors, and standardization

[adamwhitlock1]

User Story

As an engineer, I want to investigate approaches for standardizing mock API responses across the VA application ecosystem, focusing initially on the most commonly used endpoints, to reduce duplication of effort and improve local development experience.

Background

Mock responses are scattered across repositories (vets-api, vets-website) and implemented inconsistently. This leads to:

• Duplicate effort in maintaining mock data
• Inconsistent response structures
• Limited reusability across applications
• Potential divergence from actual API behavior
• Difficulty in simulating different data scenarios

Discovery Goals

1. Current State

   • Document existing mock server implementations
     • vets-website local mock server
       • applications using mock server
     • vets-api mock data
     • MSW usage in tests
     • Cypress intercepts in e2e tests
   • Identify most frequently used endpoints across applications
   • Analyze current mock response patterns in regards to what we can standardize, and where data inconsistencies

2. Response Structure Investigation

   • Study in_progress_forms/{FORM_ID} responses across different forms
   • Identify common fields and patterns
   • Document variations and special cases

3. Technical Approaches Evaluation

   • Evaluate MSW for browser-based mocking for maintainability, conciseness, and reusability
   • Compare with current Mocker-api/Express-based mock server
   • Assess feasibility of sharing mock data between vets-api and vets-website

Questions to Answer

• What are the minimum required fields for common endpoint responses?
• Can we create a tiered approach with basic/extended mock responses?
• How can we maintain mock data consistency with real API changes?
• What's the developer experience impact of different mocking approaches?
  • Can we make the experience better with combined responses that can be utilized within various environments (unit tests, e2e, local browser)

Resources

• vets-api-mockdata
• form_profile_mappings in vets-api each form can choose how their prefill data is structured, so this is one of the largest areas that could use standardization
• 21-686c prefill model in vets-api this model has more complex data that is connected so adds a layer of complexity on what can be mapped for this form
• common responses in vets-website
• Cy.intercept docs
• MSW Documentation

Deliverables

1. Analysis document covering:

   • Current state assessment
   • Identified patterns and inconsistencies
   • Technical approach recommendations
   • Implementation considerations

2. Proof of concept implementing recommended approach for 2-3 common endpoints

Success Criteria

• Clear understanding of current mock data landscape
• Documented patterns for standardizing responses
• Technical recommendation with pros/cons analysis
• Working proof of concept for selected approach

Constraints & Considerations

• Must support existing applications without breaking changes
• Should align with actual API behavior
• Consider impact on testing infrastructure
• Consider maintenance overhead

Review Needed By

• VA Product Ownder
• Product Manager
• UX Research Team
• Engineering Team

Definition of Done

• Analysis document completed and reviewed
• Technical approach recommendation made
• Proof of concept implemented
• Next steps documented

[bellepx0]

Completed part 1 of discovery. Parts 2 and 3 will be addressed in upcoming sprints.
Discovery part 1 doc

[bellepx0]

Completed parts 2 and 3 of discovery, including proof-of-concept. Doc here.

[adamwhitlock1]

I reviewed the POC branch and it works as expected.

Really great work on doing some foundational exploration into this type of idea @bellepx0 !

I also added some additional notes and general thoughts at the bottom of your google doc. We can close this as done now, and revisit next steps after the holiday / next sprint.