Cypress: Does Cypress support multiple browsers instances within a single test?

[yonatanhakatan]

For example, if you wanted to test a chat application with 2 browsers communicating with each other.

Protractor currently supports this: https://github.com/angular/protractor/blob/master/docs/browser-setup.md#using-multiple-browsers-in-the-same-test

[yonatanhakatan]

Would love to know the answer to this. If there is a better place for me to ask this, that would be equally good!

[lgandecki]

I'd love to see this as well, we do this with chimp/webdriverio currently. It allows us to easily test highly reactive apps (think: chats, but, in reality, any apps where an action of one user should be reflected in another browser)

[lgandecki]

Ok. 30 seconds later, found an answer:
https://github.com/cypress-io/cypress-documentation/issues/162

"Cypress will also never support driving more than 1 browser at a time. It is possible to synchronize Cypress with another backend process (like Selenium) to drive multiple browsers, but we believe this is completely unnecessary. If you're trying to test a chat application with two users, you can easily stub or programatically control the other user without needing an entire browser. Cypress gives you much more control over your application which avoids the need to create all the physical conditions that replicate multiple users."

[claridgicus]

+1 Please revisit this.
From an end to end perspective this is really handy as I can open a client / supplier window and await each event to finish before running the actions in scenarios where the software we are building is incredibly reactive and has various permissions / functions between users roles. (which is almost all of it)

[brian-mann]

A more in depth answer and explanation is here: https://docs.cypress.io/guides/references/trade-offs.html#Multiple-browsers-open-at-the-same-time

With that said, you can achieve this using cy.task() and invoking another service like webdriver or puppeteer.

cy.task('spawn:browser')
cy.task('do:something')

Just implement the other service in the background process and work out things like browser teardown in interactive mode.

[brian-mann]

@claridgicus many users who are writing Cypress have applications that do the same thing- and regardless, its still unnecessary to spawn an entire browser just to test this.

Just expose the seams in your application that react to the other user, and then control those directly in your tests. You won't ever need to work out all the complexity around spawning another browser, and instead you can easily test all of the edge cases that would otherwise be very difficult to try to manually recreate using real browsers.

[dziamid]

Our app is omni channel call center build on top of multiple saas backends.
The complexity involved in mocking the other side of conversation/voice
call is huge ( if possible at all ) and honestly would not give us
confidence that real thing would be 100% functional even if mocked tests
would pass. We had to switch entirely to puppeteer to be able to test
multiuser interactions and the completixy around operating multiple windows
with puppetteer is second to none. It really dawns on me why you guys cant
embace this?

On Mon, Oct 1, 2018, 00:49 Brian Mann [e-mail] wrote:

@claridgicus https://github.com/claridgicus many users who are writing
Cypress have applications that do the same thing- and regardless, its still
unnecessary to spawn an entire browser just to test this.

Just expose the seams in your application that react to the other user,
and then control those directly in your tests. You won't ever need to work
out all the complexity around spawning another browser, and instead you can
easily test all of the edge cases that would otherwise be very difficult to
try to manually recreate using real browsers.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/cypress/issues/590#issuecomment-425754828,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXQlFquf-PUZlkpf1DRRCWhlDfUDNPMks5ugTxugaJpZM4O02ay
.

[brian-mann]

Because Cypress runs in the same run loop as the browser in a completely different architectural mode and context than any other browser testing tool. There are tradeoffs involved in that, and creating API's enabling multi-browser would be a massive amount of work for a very small use case surface area.

We'd need to come up with solutions for logging multiple browsers, collecting the video of multiple browsers, screenshots, etc. There's a lot of complexity to try to pull it off in a non-hacky fashion.

I'm also not suggesting mocking the entire backend, I'm referring to mocking the wrapper API's that are invoked from the side effects. That's just one approach, there is no one-size fits all model. If you haven't built your API's in a testable fashion from the get-go, then trying to bolt on anything is going to be difficult and likely will not be easy to test in a "unit test" manner, and you'll be forced to interact with end to end tests.

With all that said - you can still achieve this in Cypress today without us touching anything by simply delegating via cy.task(...) and using a lib like puppeteer to drive the 2nd, 3rd, 4th, 5th, 1000th other browser if you'd like. All that power is already at your fingertips. You'll need to work out how to handle things like knowing when to spawn the browser and close it down as you iterate on the tests, but that is likely very specific to your own process and you can make it do whatever you'd like.

@dziamid We do fully embrace this mode of testing and our docs provide examples and multiple ways to achieve it.

[JLarky]

I recently started to use cypress to test out chat server/client. Solution to run simple node.js client that does whatever we expect 2nd/3rd user would be doing so far looks as the most promising. It does require writing separate tests to cover whatever that simple client was doing, but I come to see that this limitation is worth it in the end.

It might be the case as with unit testing: if you write software keeping unit tests in mind you are more likely to write better and more modular code. It seems like if you are writing your app having cypress testing in mind you would have to write more modular and better designed system :) In our case that turned out to be having separate library that encapsulates chat API (websocket transport) that is used for both client (web and react native) and test users. And using jwt based auth tokens, so we generate new users/teams right from our tests and staging server is configured to accept such tokens and periodically clean up after them.

Also, your cypress test are not the only tests you are using for your system, there's nothing wrong in having few tests suites that are more advanced if you need to test WebRTC between several browser vendors or something. People who are curious in this issue not necessarily can't live without multi headed cypress, they are just bummed about having to deal with far less superior tools in order to test rest of the stack :)

[sebastianjung]

I think i found a "solution" to this problem without using cy.task() or using another testing library.

DISCLAIMER: The following way of handling the tests needs some manual preparation and might therefore not suit your usecase. I do not know if this also works for when you run tests in headless mode.

You can just simpy run the cypress process two times in two different terminal windows. When both Cypress GUI Panels open up, choose "Chrome" as the browser environment for the one and "Electron" for the other testing spec. (If you choose Chrome for both, the second test won't start)

Feels a bit hacky but it fits at least my needs.

Hope this helps :)

[tommcgurl]

@sebastianjung That actually worked great for what I was trying to do 👍 thanks!