@mijogu

We want a Cypress project scaffolded and integrated with GitHub Actions for the Svelte-based web frontend under web/client within this repo. The Cypress project should include one end-to-end test for the core user workflow and several component tests for the most complicated Svelte components (.svelte files under src/lib and src/routes)

Roadmap

• Scaffold Cypress project
  • Configure the online validator instance as the default baseUrl
• [ ] Set up Cypress' Svelte integration
• Create one end-to-end test against live web service
  1. Navigate to baseUrl
  2. Input https://developers.google.com/static/transit/gtfs/examples/sample-feed.zip as URL
  3. Click Validate
  4. Intercept POST to /create-job, wait for it and assert it runs exactly once and succeeds and returns a { jobId: '...' } data structure with a nonempty jobId
  5. Intercept HEAD to /${jobId}/report.html and wait for that to happen at least once with a response status of 200 OR 404
  6. With an extended timeout, wait for the "Your report is ready!" modal to appear and verify that the link is to your ${jobId}/report.html
• Update end-to-end test to use mock API responses and not hit the real web service at all
  1. Mock the POST .../create-job request to return a hard-coded jobId
  2. Mock the HEAD .../${jobId}/report.html request to respond 404 2 times and then 200 on the 3rd request
  3. Adjust the wait for /${jobId}/report.html to have 3 hardcoded waits in serial where each asserts the correct count of calls and the return status being 404, 404, and then 200
  4. Drop the timeout on the "Your report is ready!" modal UI appearing to assert that it is displaying nearly immediately after the 3rd and final wait for report.html to return 200
• [ ] Review .svelte components and identify the 3-6 most complex ones to develop component tests for that try out different input parameters and assert on key UI elements that should reflect those inputs
• Add a new GitHub Actions workflow that runs the action provided by the Cypress project
  • Have it triggered by all pull requests against master like the acceptance_test workflow is
  • Rather than using paths-ignore like other workflows triggered by pull_request events, this workflow can just use the paths filter on web/client/**
• Add E2E test cases to trigger error displays added in feat: Web Validator Client Display Errors #1383