Skip to content

[WIP] Cache login across specs #9499

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jrafanie
Copy link
Member

@jrafanie jrafanie commented Jun 13, 2025

Seems to be cached for each spec in a file. The next file will reset the local storage and cookies so it appears to need to be done once per file.

Add validation to something that responds quickly..., /api

Previously, we'd land on /dashboard/show after login, now, visit a faster page, /utilization after establishing or restoring session.

TODO:

  • We should probably clear the shared session or ensure we use a separate session for the login tests.
  • Ensure we're not sharing session information beyond login. Things like previously open trees, nodes, etc. will likely cause test contamination if it's stored in session. We want the shared login but nothing else.
  • The redirect after login loading /dashboard/show is a waste of time. Only dashboard tests need that page. For now, I did some other faster page but ideally, we could login without a redirect and each test could say what URL that start on. I'm not sure how much if that's feasible and may introduce other problems in the application in service of cypress testing, so it's possibly not a good idea.
  • I don't know if it's possible to share the login across test files. In other words, I think the most we can do is share the login with the same test file.

Seems to be cached for each spec in a file.  The next file will reset the local storage
and cookies so it appears to need to be done once per file.

Add validation to something that responds quickly..., /api

Previously, we'd land on /dashboard/show after login, now, visit
a faster page, /utilization after establishing or restoring session.
@jrafanie jrafanie requested a review from a team as a code owner June 13, 2025 22:43
@miq-bot
Copy link
Member

miq-bot commented Jun 13, 2025

Checked commit jrafanie@aae7350 with ruby 3.1.5, rubocop 1.56.3, haml-lint 0.62.0, and yamllint
0 files checked, 0 offenses detected
Everything looks fine. 🏆

@jrafanie jrafanie closed this Jun 16, 2025
@jrafanie jrafanie reopened this Jun 16, 2025
@Fryguy
Copy link
Member

Fryguy commented Jun 16, 2025

utilization is an odd choice but I honestly don't have anything better - maybe don't go anywhere at all, and each test needs to assume it can be anywhere and could go where it wants in the respective before?

@Fryguy Fryguy self-assigned this Jun 16, 2025
@jrafanie
Copy link
Member Author

utilization is an odd choice but I honestly don't have anything better - maybe don't go anywhere at all, and each test needs to assume it can be anywhere and could go where it wants in the respective before?

I wanted to avoid the dashboard with those charts. Utilization or optimization are both pretty small in comparison. Perhaps we can intercept/mock those chart/report widget requests but we still spend time drawing them.

Ideally, login wouldn't redirect anywhere as that's a wasted page load. Tests should assert which URL they should start on after login. For now, a less heavy page like utilization or optimization might be fine even if we're wasting time loading a page for each test even thought it's not needed.

I think some of the failures that can occur with this PR is that we remember where we were in some of the pages so we are introducing a new way to contaminate tests.

@Fryguy
Copy link
Member

Fryguy commented Jun 16, 2025

We do have the concept of a landing page which is user-specific, and we only allow certain pages. Thinking out loud but it's possible we could leverage that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants