Cypress Sessions Experimental Feedback #17887
Replies: 19 comments 43 replies
-
|
It's excellent, the api is very intuitive by describing the users actions and not the technical end result. So far the functionality has worked for me flawlessly as well. However I'm not keen on the presentation. The sessions part describes clearly what session was used and you have the ability to clear sessions 👍. But when a test kicks off, it runs through the session first and it's often at odds with what you're expecting the test to do. I would like to see a clearer visual indication that cypress is building a session first, perhaps by:
In addition when the test is finished, the session detail is recorded under the "Test body", whilst that is technically correct I consider sessions to be somewhat of a "setup to the test". I feel like it should be recorded under the "Session tab", it just needlessly clutters the test body to me. Really, a big thank you for the work on this though. It's greatly simplified some of the boilerplate user actions that couldn't be articulated well. |
Beta Was this translation helpful? Give feedback.
-
|
It's not as flexible since it require us to use cy.visit() after |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand your point, why would you not have them to hand? How would you have visited that page to begin with? |
Beta Was this translation helpful? Give feedback.
-
|
Firstly you visit /users route to check smth |
Beta Was this translation helpful? Give feedback.
-
|
So what's the issue with that? You have the url to use in the session, and then the user and contract you want to visit after? |
Beta Was this translation helpful? Give feedback.
-
|
To visit /user/12/contract/12/display=true |
Beta Was this translation helpful? Give feedback.
-
|
All easy-peasy using cypress-data-session
…Sent from my iPhone
On Sep 30, 2021, at 13:05, Roman Khomitskyi ***@***.***> wrote:
To visit /user/12/contract/12/display=true
You will have to grab user id and contract id from database and only then build up url
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
I was very happy to find an use cy.session(), because my user creation and login process involves sending an email with a magic link and creating and using a two-factor authenticator. It's not a simple set of API commands to create a user and login with a password. Unfortunately, I quickly hit #17710, finding out that session data is not cached across specs. Is there a reason for that, or is it a bug? Based on some of the discussion leading up to the creation of cy.session (e.g. #686 and #2951 (comment)) that this new session api would be a way to speed up tests by storing session data across tests. |
Beta Was this translation helpful? Give feedback.
-
|
@IanVS When |
Beta Was this translation helpful? Give feedback.
-
|
Hi all, I've been trying to get some kind of cookie storage working for the better part of this evening. I finally stumbled upon all those tickets saying This is a very condensed example (I tried it with the official https://docs.cypress.io/api/commands/session#Updating-an-existing-login-helper-function version first). And yes the whole login procedure itself works just fine. it("successful login", () => {
cy.session("login", () => {
cy.visit("/");
cy.get("#id_login").type("loginname");
cy.get("#id_password").type("loginpassword");
cy.get(`input[type="submit"]`).click();
cy.url().should("eq", "http://localhost:8000/");
cy.hash().should("eq", "");
})
cy.visit("/")
});Am I understanding it correctly and should i expect the final And I tried any possible way I could think of but it feels like no matter what I do, When I watch the cookies in the browser I see them being consistent until the new Please help ❤️ PS: newest Cypress 8.6.0 and Chrome 94. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this looks correct. If you click on the session in the Command Log with DevTools open, it should log the cookies/localStroage/sessionStorage that Cypress was able to save here. Do you see anything in there?
|
Beta Was this translation helpful? Give feedback.
-
|
I still don't exactly know what's going on, but it seems like it's the underlying Django with a specific set of odd cookie-settings, that is forcing this problem. So as far as I can see, it's not a Cypress problem as such. I'll keep you posted |
Beta Was this translation helpful? Give feedback.
-
|
Hello @jennifer-shehane , thank you for getting back to me, this is the result. as you can see, the thank you |
Beta Was this translation helpful? Give feedback.
-
|
First of all sessions are awesome, I played with them a little more yesterday and I’m super impressed 👍 I have a question though. Is it possible to load information from cached session and use it elsewhere in test? Let’s say I have a test like this: cy.session([username, password], () => {
cy.request({
method: 'POST',
url: '/login',
body: { username, password },
}).then(({ body }) => {
window.localStorage.setItem('authToken', body.token)
})
})But I want to use that local storage item in another place in test, for example in a request command, like this: cy.session('mySession')
cy.request({
method: 'POST'
url: '/example',
headers: {
authorization: // here I’d like to use the cached session dataa
}
}) |
Beta Was this translation helpful? Give feedback.
-
|
@filiphric use the function login(username, password) {
cy.dataSession({
name: username + password,
setup() {
cy.request({
method: 'POST',
url: '/login',
body: { username, password },
}).then(({ body }) => {
return cy.wrap(body.token)
})
},
validate(token) {
return Boolean(token)
},
recreate(token) {
window.localStorage.setItem('authToken', token)
}
})
}
// now you want to get access to the token for the user
login(username, password)
.then(function () {
// use the data session name as an alias
// it will have the token
cy.request({
headers {
authorization: this[username + password]
}
})
}) |
Beta Was this translation helpful? Give feedback.
-
|
Wow this plugin took the session API to a whole another level. Is there any reason to keep this plugin separate from codebase? I find this to be a great addition to the overall Session API experience |
Beta Was this translation helpful? Give feedback.
-
|
You know I save the best for you
…Sent from my iPhone
On Oct 15, 2021, at 07:15, Filip Hric ***@***.***> wrote:
Wow this plugin took the session API to a whole another level. Is there any reason to keep this plugin separate from codebase? I find this to be a great addition to the overall Session API experience
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
In the future do know if there is going to more flexibility around I currently achieve this by using |
Beta Was this translation helpful? Give feedback.
-
|
Exactly, there is no flexibility in using cy.visit in each test, it makes tests really slow |
Beta Was this translation helpful? Give feedback.
-
|
I agree, it make the test really slow and inefficient. You basically can only test pages and not actual user flow. |
Beta Was this translation helpful? Give feedback.
-
|
@shutchison-bai #23503 is currently in review to remove the page clearing after |
Beta Was this translation helpful? Give feedback.
-
|
Please see response above: #17887 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
Posted from a ticket I had added to the issues board. What would you like?With Cypress The mandatory page clearing, in my humble opinion, is a straight up no-go. This should be toggleable (default to true/false... whatever). Similar to how a validate option is passed... so like Why is this needed?Mandatory page clearing everytime you move to a new but now we basically are forced to, because of the new This is a very contrived example, and if I were to copy/paste the actual code, the resulting For what it's worth, I too agree that cypress tests should NOT be written akin to some integration/unit test (with the whole assemble, act, assert paradigm). But, also I don't think one should jam 1000 lines of code inside a single EDIT: Also forgot to mention that potential metric ton of refactoring one might need to do when suddenly switching to |
Beta Was this translation helpful? Give feedback.
-
|
Sure thing. So the reason is when the session is restored, and the setup is not run, your test runs it won't be at |
Beta Was this translation helpful? Give feedback.
-
Thank you |
Beta Was this translation helpful? Give feedback.
-
|
@emilyrohrbough Thanks tons for the response!
I get what you're saying. To be fair though, I really don't think this is something that the cypress team ought to take on... Not their responsibility. But that's just my 2 cents from a random internet stranger of many millions of engineers out there :D Just like we can all write integration tests which talk with a database, there's nearly no suite out there in any language/framework which prevents one from having isolated tests. Same with unit tests... one could still glom together their tests and rely on previous tests. Not saying one should do this, just saying that ultimately the power is up to the developer. Something like this needs to be up to the engineer(s) whom implement their suite of tests, and not mandated by the tool itself. I get the essence of what's trying to be achieved w/ cy.session and reloading the page... but ultimately this just causes some serious problems with apps which load lots of resources. Simple, small apps with magnificent page load speeds it's likely less of an issue. I feel like cy.session should be concerned with one thing, and one thing only... dealing with the cookies/session state and restoring them when the developer calls for it. Leave the page clearing/loading up to them. |
Beta Was this translation helpful? Give feedback.
-
|
Based on multiple users feedback around this undesired behavior, I am in the process of syncing with our Product Team to determine what we might be able to offer users to give them the safest command behavior and/or an option remove this command-level isolation. At this time I can't say for sure if this is work will be willing to support, but it is a conversation that is happening. |
Beta Was this translation helpful? Give feedback.
-
|
@rkhomi / @romankhomitskyi / @shutchison-bai / @stokrattt / @dakur / @dvsoukup We have taken this feedback and as at team we evaluated the test isolation behavior and found it wasn't behaving how users expected and have made adjustments. In Cypress 10.11.0, the way that Cypress handles test isolation changed. The previous modes of
To accomplished the example provided above, you will need to set |
Beta Was this translation helpful? Give feedback.
-
|
Cypress.Cookies.defaults Work much better and faster than cy.session() Even without cy.session my tests are independent and reliable |
Beta Was this translation helpful? Give feedback.
-
|
Totally agree as well. Not only it will make tests slower, but it's kind of anti-pattern as tests won't be behaving like carbon based user anymore :( |
Beta Was this translation helpful? Give feedback.
-
|
cy.session -> really breaks custom logic |
Beta Was this translation helpful? Give feedback.
-
|
@jitenev > cy.session -> really breaks custom logic Can you share what type of custom logic breaks with |
Beta Was this translation helpful? Give feedback.
-
|
Hi! The But I have one problem with it - it doesn't work for headless mode, which is more important for me! Here is the reproduce (open with gitpod). You can see that every test took 3sec, but this delay should not be executed for each test except first, because it in the session, is it correct? What I was missing in my code? |
Beta Was this translation helpful? Give feedback.
-
|
@artalar Two things here:
|
Beta Was this translation helpful? Give feedback.
-
|
@jennifer-shehane We have Cypress 10.4 available and call for feedback here, but no one from the team has replied to the raised problems for many months. Can something be done please? Personally, I'm stuck on v9 as I have no clue how to go with the new session API without squashing all my tests into in big |
Beta Was this translation helpful? Give feedback.
-
|
@dakur Please see the reply above. |
Beta Was this translation helpful? Give feedback.
-
|
Consider this example, we have simple crawler test suite, I just wanna go over sidebar and navigate to a bunch of pages and just check page title To have this more readable I split it into several it's() to have nice report and know exactly where the page title was changed Cypress.addCommand('login', () => {
cy.session('authenticatedUser', () => {
cy.visit('/login')
cy.get('username').type('user', { log: false })
cy.get('password').type('password', { log: false })
cy.get('submit').click()
}, {
validate: () => {
cy.visit('/home')
cy.contains('Welcome User')
cy.window().then((win) => {
expect(win.localStorage.length).to.eq(2)
})
}),
})
before(() => {
cy.login()
})
it('test page 1', () => {
sidebar.goToPage(1)
cy.contains(Page 1)
})
it('test page 2', () => {
sidebar.goToPage(2)
cy.contains(Page 2)
})but this won't work since each sidebar click changes the url before(() => {
cy.login()
})
it('Check pages', () => {
sidebar.goToPage(1)
cy.contains(Page 1)
sidebar.goToPage(2)
cy.contains(Page 2)
})which is less readable How about to add an option to not clear localStorage and cookies at all? That is default behaviour in all others frameworks |
Beta Was this translation helpful? Give feedback.
-
|
@rkhomi Is there a reason you cannot' use your login command in a |
Beta Was this translation helpful? Give feedback.
-
|
The reason is that login in beforeEach will make it this test suite slower)) Same goes if I were to check that Upgrade plan Stub is shown on specific pages for user with Free subscription plan I would just put Stub assertion for specific page in saparate it() and it would be much faster just to navigate across the webstie using only one session It's just SPA |
Beta Was this translation helpful? Give feedback.
-
|
I mean, why do I have to use login request and cy.visit(/) when it takes let's say 5 seconds every time, if I could end entire test suite in 5 seconds? |
Beta Was this translation helpful? Give feedback.
-
|
I am running into the same issue and not upgrading because of it. |
Beta Was this translation helpful? Give feedback.
-
|
Please see response above: #17887 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
I ran into a problem, POST request changes the session. Cypress.addCommand('login', (email: string) => {
cy.session(email, () => {
cy.visit('/login')
cy.get('username').type(email)
cy.get('password').type('password')
cy.get('submit').click()
}
Cypress.Commands.add('deleteUser', (email: string) => {
cy.login(ADMIN_USER.email)
cy.visit('/admin/users')
cy.get('username').type(email)
cy.get('button[type="submit"]').click()
})
Cypress.Commands.add('createUser', (user: SignUpFormUser) => {
const data = {
email: user.email,
password: user.password
}
cy.request({
method: 'POST',
url: '/api/reg/',
body: data,
})
})
Cypress.Commands.add('reCreateUser', (user: SignUpFormUser) => {
cy.deleteUser(user.email)
cy.createUser(user)
}) |
Beta Was this translation helpful? Give feedback.
-
|
@vbukin This question / example doesn't seem specific to the cy.session() command or Test Isolation. If you want to validate a POST request without it impacting cookies on our page, I recommend giving |
Beta Was this translation helpful? Give feedback.
-
|
I think this feature makes it worse with regards to cookie state management. First it was very clear what cookies we allowed to keep during a suite. But now for some clients this will become a nightmare (many added visits and more complexity in code) when we want to keep CY latest. For example one client is using keycloak, where the whole util is in I can only hope you will think about integrations as well. And not the simple ones where login is part of the application. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @emilyrohrbough i can understand you will not reply on all topics raised. But in my case i can not set one generic toggle on or off. I had the option to put it on/off per testing suite. So before i had in one suite: while other suites where done in total isolation. How can i proceed now for the future of using Cypress? cy.session is not working for the keycloak example for example (user not really logging in but doing some http calls in the keycloak commands) and i have other big users as well who never have an actual login form as part of their own suite but using helpers ... |
Beta Was this translation helpful? Give feedback.
-
|
@maapteh You can configure this at the suite level -- which is actually recommended to only turn off where needed: describe('suite', { testIsolation: 'off' }, () => {
...
} |
Beta Was this translation helpful? Give feedback.
-
|
It would be really really great if we got an option to not clear local storage and cookies at all Or at least, clear local storage only once before spec starts executing |
Beta Was this translation helpful? Give feedback.
-
|
Please see response above: #17887 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
But thats not per testing suite right, its for all the tests, or is my lack of english not helping by reading the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
@maapteh It can be for all tests or it an be per-suite like: describe('suite', { testIsolation: 'off' }, () => {
...
} |
Beta Was this translation helpful? Give feedback.
-
|
From 10.11, there is |
Beta Was this translation helpful? Give feedback.
-
|
I've used cy.origin and cy.session and the majority of scenarios behave as expected. For this application users authenticate on one domain and then are redirected to the main site. There're two particular scenarios I haven't managed to solve; signing out of the application or updating a user display name. When a user clicks the relevant buttons for these scenarios nothing happens. (These scenarios work fine if origin is not used). I believe the reason it could be causing an issue is that the requests are doing a call-back to the first domain to fetch/update the user token, but without navigating outside the second domain. Is there something I've missed on how to handle this? |
Beta Was this translation helpful? Give feedback.
-
|
@kathryn-p I'm sorry to hear you are having issues. Would you mind opening an issue around this use case with instructions on how to replicate? |
Beta Was this translation helpful? Give feedback.
-
|
Any plans on including IndexedDB in the mix? Using the session API in combination with Firebase Auth presents some challenges, since Firebase saves data in IndexedDB and the session API does not handle that. Would love to help! Is there anything I can do? Also, can anyone recommend a workaround? |
Beta Was this translation helpful? Give feedback.
-
Hey everyone, thanks for testing out the experimental
cy.session()!We appreciate any and all feedback that you have to provide. Please use this thread to provide feedback, request features, or just comment on
cy.session()in general.If you have a larger bug to report, please file a dedicated issue.
Docs: https://docs.cypress.io/api/commands/session
Beta Was this translation helpful? Give feedback.
All reactions