I have a complex SPA that allows users to chat with one another. I am banging my head against several walls trying to even understand how Selenium works. I discovered Cypress, and -- apart from a very long list of opened issues -- it sounds like the holy grail. However, in my tests I need to:
Looking at the API, and the way you serialise commands, I am afraid that this is impossible.
Can you please confirm that my use case is not covered by Cypress?
Or, can you explain how to do it.
THANK YOU! I hope Cypress becomes the new Selenium
I received a notification email with the following:
Firefox support is coming, and the proposal for cross browser support is complete, as per their roadmap:
https://docs.cypress.io/guides/references/roadmap.html#Upcoming-Features
I just wanted to clarify that I am NOT after cross-browser support. I want to open THREE instances of Chrome, and then "pilot" each browser to run different tests.
Yes I noticed that, that's why I deleted my comment.
Did you try running multiple instances of cypress, each one running a different spec?
I can't do that, because the main point of having different browsers running is that User A on browser A sends a message to User B on Browser B. The test will make sure that User/Browser B actually get the message...
So, can't you do something like:
In one spec, you put a wait of 2s for user A to wait for the cypress instance of user B to run, then send the message.
In another spec, you put a cy.wait of 5s, to wait for the message from the user A to reach your client.
This seems like a really dirty workaround though, have you looked into stubbing network requests?
(Edit)
This way you can create a spec that tests an user B receiving a stubbed request from "user A", eliminating the need for different browsers and tests running at the same time.
We've answered this question in detail and provided several ways of testing this. Long story short - you don't need multiple browsers to test this.
https://docs.cypress.io/guides/references/trade-offs.html#Multiple-browsers
I respect the work you are doing, but I think you need to be a little honest.
"You can't really run tests using different browsers, end of story"
What you are saying is "you don't need to" and then you point to a doc that says things like:
"Trying to spin up the entire environment is a race to the bottom. Imagine when you want to test the collaboration of 3 users, then 4 users, then 5 users. Handles the load of dozens, hundreds, or maybe thousands of users. Would you spin up a browser to simulate the environment for each one of them?"
If you read Schopenhauer's "the art of being right", you will see that this is the very _first_ trick: "The extension". It goes like this:
This consists in carrying your opponent's proposition beyond its natural limits; in giving it as
general a signification and as wide a sense as possible, so as to exaggerate it;
I never said I wanted to use different browser to stress test. And in fact it's a very silly argument.
The doc you mentioned then says "Avoid the server, invoke your JavaScript callbacks manually thereby simulating what happens when ānotifications come inā, or āusers leave the chatā purely in the browser." Yeah, that's called unit testing, and my application has those pouring out of its (virtual) ears. What I am trying to do, in fact, is _integration_ testing. If user A writes to user B, I want to check that user B first sees the "User A is typing" in the screen, and eventually -- after the message is submitted -- that user B receives the message. I mentioned this because this is a REAL case where a bug only EVER shows up while interacting with the server for real. Unit testings didn't catch this one.
Please don't get me wrong: I think what you are doing is awesome. But, I think that you need to put the honest hat on, and just say "Sorry, with Cypress, as awesome as it is, you can only ever run tests using _one_ browser". You will still cover 99% of your user base, so you are fine. And the remaining 1% will appreciate your honestly.
IMHO, you should do these types of integration testing on the back-end.
YAGNI on the front-end, you should stub the backend and make sure the components/UI behave the way you intended.
Hi @mercmobily, I created a new issue in our docs to address the tone of the document you mentioned here: https://github.com/cypress-io/cypress-documentation/issues/392. You haven't been the first to point out some issues with it.
Our documentation is open source and contributions are welcome. š
@mercmobily I agree with some of your points - however you say here:
But, I think that you need to put the honest hat on, and just say "Sorry, with Cypress, as awesome as it is, you can only ever run tests using one browser".
That is literally the very first line of this part of the document which is in the "Trade-Offs" section!
With that said - it is not impossible to do, as per the second sentence that we have actually seen this work. So what we're saying is: 1) it will never be natively supported in Cypress and 2) you can still do it if you really want to.
The rest of the argument is more or less trying to convince you that there is likely a better approach than spinning up multiple browser and testing their collaboration.
I agree that if you're trying to write as pure as integration tests as possible - that you would not invoke JS callbacks directly (as that would be akin to a unit test).
However the document also provides examples of causing the integration at the server level -
therefore testing the entire integration between the client and the server (even providing some sample code by which to do this). I think if you took that approach, you wouldn't have to spin up 2-4 more browsers, still retain 100% coverage, test every edge case, and ensure everything is working without breaking a sweat.
Apologies, yes, I had basically missed the very first sentence of that section. Go figure.
While I still think there are some use cases (like mine) where multiple browsers are borderline necessary, you do say it very clearly in the docs. I guess the only part that really struck me was:
Trying to spin up the entire environment is a race to the bottom. Imagine when you want to test the collaboration of 3 users, then 4 users, then 5 users. Perhaps you then want to test how your backend handles the load of dozens, hundreds, or maybe thousands of users. Would you spin up a browser to simulate the environment for each one of them?
This, I would frankly take out. The rest is a solution that will work for the majority of people.
Apologies for missing the... err... very first line of that section.
I opened a PR for the docs - hopefully this is better. Let me know if you have any more feedback. https://github.com/cypress-io/cypress-documentation/pull/395
With that said - it is not impossible to do, as per the second sentence that we have actually seen this work. So what we're saying is: 1) it will never be natively supported in Cypress and 2) you can still do it if you really want to.
are there any examples for using 2 different browsers/tabs?
@mercmobily FYR, Selenium based solutions do support spawning multiple browser instances and switching between them, so consider using them, e.g. Protractor.
If you really want to stick with Cypress, i'd suggest you stub request for another user in your test cases. E.g.:
Thank you dziamid. Unfortunately, I feel that the node API for selenium is severely over-engineered. Which is why 13 days ago I wrote, documented and tested best-webdriver which comes with full API.
So, I won't be using Cypress -- but, I have to say, if I hadn't had a strict requirement of multiple sessions, I would have saved myself 2 weeks of hard work and used your great solution!
how I could change the language of my browser before the test run in cypress
they are a config like Cypress.config('language', 'en_EN.UTF-8'); ??
@lmorissette I think you may be looking to set the Accept-Language
header during cy.visit()
https://github.com/cypress-io/cypress/issues/1904
I did it using selenium-webdriver as node backend processor in cypress
https://medium.com/@kamran.athar23/cypress-and-selenium-together-to-achieve-multiple-browser-testing-409e2af77838
Most helpful comment
I respect the work you are doing, but I think you need to be a little honest.
"You can't really run tests using different browsers, end of story"
What you are saying is "you don't need to" and then you point to a doc that says things like:
"Trying to spin up the entire environment is a race to the bottom. Imagine when you want to test the collaboration of 3 users, then 4 users, then 5 users. Handles the load of dozens, hundreds, or maybe thousands of users. Would you spin up a browser to simulate the environment for each one of them?"
If you read Schopenhauer's "the art of being right", you will see that this is the very _first_ trick: "The extension". It goes like this:
I never said I wanted to use different browser to stress test. And in fact it's a very silly argument.
The doc you mentioned then says "Avoid the server, invoke your JavaScript callbacks manually thereby simulating what happens when ānotifications come inā, or āusers leave the chatā purely in the browser." Yeah, that's called unit testing, and my application has those pouring out of its (virtual) ears. What I am trying to do, in fact, is _integration_ testing. If user A writes to user B, I want to check that user B first sees the "User A is typing" in the screen, and eventually -- after the message is submitted -- that user B receives the message. I mentioned this because this is a REAL case where a bug only EVER shows up while interacting with the server for real. Unit testings didn't catch this one.
Please don't get me wrong: I think what you are doing is awesome. But, I think that you need to put the honest hat on, and just say "Sorry, with Cypress, as awesome as it is, you can only ever run tests using _one_ browser". You will still cover 99% of your user base, so you are fine. And the remaining 1% will appreciate your honestly.