3141 - fix cypress

[jtimpe]

Summary of Changes

Pull request closes #3141

• fix cypress e2e tests logging in as the wrong user. Two parts to this
  1. call cy.visit('/') before adminLogin, so that the page is first accessed from a logged-out state
  2. call cy.clearcookies() before cy.visit('/') on regular-user login, so that any cookies grabbed from adminLogin are removed

How to Test

1. Open cypress.config.js and make the following changes

   baseUrl: 'https://tdp-frontend-raft.app.cloud.gov',
   env: {
     apiUrl: 'https://tdp-frontend-raft.app.cloud.gov/v1',
     adminUrl: 'https://tdp-frontend-raft.app.cloud.gov/admin',
     cypressToken: '',  // get this from cloud.gov env (or reach out to me)
   }

2. Run

   cd ./tdrs-frontend
   npm run test:e2e

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

• Fix tests
• lfrohlich and/or adpennington confirmed that ACs are met.

Deliverable 2: Tested Code

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces backend code changes, are they meaningfully tested?
  • If this PR introduces frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: [insert coverage %] (see CodeCov Report comment in PR)
  • Backend coverage: [insert coverage %] (see CodeCov Report comment in PR)

Deliverable 3: Properly Styled Code

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?
• Are code maintainability principles being followed?

Deliverable 4: Accessible

• Does this PR complete the epic?
• Are links included to any other gov-approved PRs associated with epic?
• Does PR include documentation for Raft's a11y review?
• Did automated and manual testing with iamjolly and ttran-hub using Accessibility Insights reveal any errors introduced in this PR?

Deliverable 5: Deployed

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

• Does this PR provide background for why coding decisions were made?
• If this PR introduces backend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces frontend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces dependencies, are their licenses documented?
• Can reviewer explain and take ownership of these elements presented in this code review?

Deliverable 7: Secure

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any new security issues?
• If new issues detected, is investigation and/or remediation plan documented?

Deliverable 8: User Research

Research product(s) clearly articulate(s):

• the purpose of the research
• methods used to conduct the research
• who participated in the research
• what was tested and how
• impact of research on TDP
• (if applicable) final design mockups produced for TDP development

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.52%. Comparing base (bf0bcec) to head (6e22311).
Report is 4 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3260   +/-   ##
========================================
  Coverage    91.52%   91.52%           
========================================
  Files          297      297           
  Lines         8415     8415           
  Branches       608      608           
========================================
  Hits          7702     7702           
  Misses         603      603           
  Partials       110      110           

Flag	Coverage Δ
dev-backend	91.37% <ø> (ø)
dev-frontend	92.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f8e618a...6e22311. Read the comment docs.

[raftmsohani]

can't we store the admin and user separately and use them from store as necessary, instead of deleting them?

[ADPennington]

@jtimpe 🆙

[jtimpe]

this is technically what's being done already via the following calls in cypress/support/commands.js

// regular login
cy.getCookie('sessionid').its('value').as('userSessionId')
cy.getCookie('csrftoken').its('value').as('userCsrfToken')

// admin login
cy.getCookie('sessionid').its('value').as('adminSessionId')
cy.getCookie('csrftoken').its('value').as('adminCsrfToken')

this takes the value from the cookie immediately after login and stores it in the cypress intermediary variable, which lives for the test run. So the cy.clearCookie and cy.setCookie apply to the browser window during the test run and use the stored values.

We should do better caching of the vars so that we don't have to re-login both users before every test, but that's covered in a followup ticket #3274

[raftmsohani]

LGTM only have a question but the solution works

[ADPennington]

confirmed with @jtimpe that this is fixing an issue on develop branch only. bypassing qasp. please feel free to merge when ready 😄