Currently, we have an end-to-end test that cycles through all the <a> links on the public facing pages of ReportStream and makes sure it returns a 200 success response. The issue with this is that, in staging, where the test runs, our app doesn't properly handle 40* error responses in our routes outside of Azure.
This has allowed a "broken" link to be uncaught by the link checker E2E test.
Impact on ReportStream
Via automation, we can't check if our internal facing links are broken.
for the link checker, for relative paths, we always check against production. pitfall here is that if you're adding brand new pages or moving the paths, they'll spit out a warning in the test until we deploy the change.
we properly handle 400 errors in our app so relative paths spit out the proper error.
for relative paths, we have our e2e code logic read the the actual HTML content on the page for something like Page not found which will work for both testing and production, but obviously this test is a little more brittle.
Acceptance Criteria
[ ] The E2E test that checks the ReportStream website links that are either invalid or return a "page not found" response trigger at least a warning when running the test
chatted with @penny-lischer and we've decided we should go for the simplest solution which is pointing relative path base paths to: https://reportstream.cdc.gov/
Describe the bug
Currently, we have an end-to-end test that cycles through all the
<a>
links on the public facing pages of ReportStream and makes sure it returns a200
success response. The issue with this is that, in staging, where the test runs, our app doesn't properly handle40*
error responses in our routes outside of Azure. This has allowed a "broken" link to be uncaught by the link checker E2E test.Impact on ReportStream
Via automation, we can't check if our internal facing links are broken.
Additional context
a couple of solutions:
Acceptance Criteria