Create Local Testing Environment

[mchae-nava]

Issue Description

In lieu of (or while we wait for) actual resources to incrementally test our migration, we can manually orchestrate a solution that can serve our purposes. This item is a bet; while it's feasible on paper, it may encounter issues that disqualify it for its intended purpose.

• For simplicity's sake, we should keep this local. Has the benefit of being inherently safer to implement
• For the purposes of integration (and also simplicity), let's also use existing va.gov data sources
• • https://github.com/department-of-veterans-affairs/va-virtual-agent/wiki/Test-Users#creating-custom-test-users
• • Aaron Young may be a helpful resource if any hiccups are encountered
• Since this is a local solution, we can default to mocked authentication, but be wary of differences this may cause with prod

In sum, the solution will likely involve a few parts:

• A branch of vets-api-mockdata with some preliminary test user profiles
• A branch of vets-api with all LH feature flags on, and pointed at the desired envs
• • Desired envs include LH endpoints, and then datasource that allows e2e test flows
• • "Golden Image" behavior, meaning the branch will serve as a template image
• • Branch will never merge into master, it will only ever be downstream
• • Once set, the image is only updated from master
• • Environments must be branched from the Golden Image
• • Environments can be updated freely, but ideally should only have in-review changed merged in
• If necessary, a branch of vets-website > this should not be necessary ideally

Some considerations for follow-up once we have an environment:

• Dry run of eVSS shutdown
• Dry run of middleware retirement
• Integration and/or e2e tests of previously completed migration items

---

Tasks

• [ ] Consider differences Mocked Authentication may have with prod
• [ ] Create a "Golden Image" branch that integrates with LH
• [ ] Create a set of our own test users to be used locally (local branch of vets-api-mockdata)
• [ ] Write a playbook for testing process
• [ ] Consider fallback behaviors for incomplete LH features
• [ ] Consider any sophistication we might need in error reporting in this branch

Acceptance Criteria

• "Golden Image" branch
• [ ] Any LH gating feature flags are off or bypassed in branch
• [ ] "Golden Image" runs locally with frontend and makes calls to LH
• [ ] "Golden Image" uses our own test users
• [ ] This test environment has sufficient parity with staging/prod
• Playbook
• [ ] Playbook details testing process
• [ ] Playbook is somewhere easily accessible

---

How to configure this issue

• [ ] Attached to a Milestone (when will this be completed?)
• [ ] Attached to an Epic (what body of work is this a part of?)
• [ ] Labeled with Team (product support, analytics-insights, operations, service-design, Console-Services, tools-fe)
• [ ] Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
• [ ] Labeled with Type (bug, request, discovery, documentation, etc.)

[RakshindaAslam]

@mchae-nava - can we look at figuring out answers to these questions to help prioritize it? Can we also get all DBEX 1 engineers to review and discuss it before bringing it for refinement?

• What problem will this solve?
• How much time will it take to build vs how much time are we expecting to save with this proposal during the migration work(ETA Q3)
• Considering that migration is the most urgent initiative, is this the right time to consider starting this work?

[mchae-nava]

@RakshindaAslam Absolutely! I've actually brought this up a few times while you were out. This is actually a follow-up to a previous item we brought into a previous sprint because it was closely related to blockers we were encountering with ITF integration testing.

What problem will this solve?

• Right now, the migration is stalled on anything that involves a click test or POST request (ITF currently, but will also apply to submit, potentially others)
• It's hard to say anything is finished conclusively until we're able to test properly
• This work will open the door to other critical parts of the migration that we may not have fully accounted for yet (e2e, rollback simulation, retirement of middleware)

How much time will it take to build vs how much time are we expecting to save with this proposal during the migration work(ETA Q3)

• In my opinion, this will be quicker and easier to implement than the ITF integration testing ticket, will cover that base and then some, so there's immediate value

Considering that migration is the most urgent initiative, is this the right time to consider starting this work?

• This is a critical part of ensuring our portion of the migration is successful, not auxiliary work
• We are already encountering some speed bumps related to not having comprehensive testing tools. This will prevent us from shipping down the line if we're not given an "official" solution, which could take months

[pacerwow]

@mchae-nava can this be closed?