Add the capability to perform testing in multiple browser windows

[inikulin]

Are you requesting a feature or reporting a bug?

Feature

What is the current behavior?

You can run test only in single window of the browser

What is the expected behavior?

It's useful to run test in multiple windows to simultaneously observe results from different users perspective. E.g. we test online chat or online game. The idea is to spawn new windows in test and switch test context to that window (It also we'll play well with Roles feature):

test('Multi-window', async t => {
     await t
           .switchRole(user1)
           .click('#start-game')

           .switchToWindow(1)   // Spawns new browser window if it wasn't used before
           .switchRole(user2)
           .click('#start-game')
           .click('#shoot')

           .switchToWindow(0); // Return to default window

    expect(await healthbar.value).eql(0);   
});

The syntax is still a subject for bikeshedding. \cc @DevExpress/testcafe

[jakearchibald]

Is the as method above part of the proposal, or something existing?

Note that this may need to be two profiles rather than two windows. You may even want to test multiple windows of multiple profiles.

as(user1) would work pretty well if user1 were created with new BrowserProfile(). Since a new profile implicitly means new window, you wouldn't need switchToWindow until you wanted to support multiple windows within the same profile.

[inikulin]

Hi Jake.

Note that this may need to be two profiles rather than two windows. You may even want to test multiple windows of multiple profiles.

This is exactly what this function do, it's a part of upcoming Roles functionality.

Update: I've forgot that we decided to use switchRole() instead of as(). I'll edit the example in OP post.

[jadechip]

Is this still on the list? Multiple browser window support would be awesome for things like auth0/google authentication.
Btw, I love TestCafe <3

[Lukukas]

I really like testcafe, but this is something I would need to successfully test my application. Our application opens multiple windows and uses them to pass data around. I would also be curious to know the timeline for this particular feature as I'm still in the process of selecting a UI automation framework.

[miherlosev]

Hi @skogman and @Lukukas
Unfortunately, I cannot provide a strong timeline.
We have plans to investigate the possibility of multiple window testing in one of the nearest sprints. We will publish investigation results as soon as they appear.
At present, you can try this workaround for the 'Logging in via a social network' case.

[SergeyShurygin]

hi @presian,

TestCafe automatically switches to a newly opened browser window. Can you describe you scenario in greater detail or create a simple example where it does not do this? Also, the getCurrentWindow method from the mentioned #5034 PR will return the new window if it was opened.

[presian]

Hi @SergeyShurygin
I tested it in a simple Angular project and you are actually right. TestCafe switches to the newly opened browser window.
But the project that I want to test is one giant JS Frankenstein and it doesn't work against it. Perhaps there is some code that returns the focus to the parent browser. So for my case, I am not able to switch to the newly opened browser. Anyway, if there is a list of object representations for all opened windows that allow us to identify the desired window in between all and switch to it will be very helpful.

Unfortunately am not able to reproduce the same behavior in a simple project for illustration.

[miherlosev]

Hi @presian

Perhaps there is some code that returns the focus to the parent browser. So for my case, I am not able to switch to the newly opened browser.

It looks like a TestCafe problem. Can your share your web application to investigate the problem?

Anyway, if there is a list of object representations for all opened windows that allow us to identify the desired window in > between all and switch to it will be very helpful.

I created a suggestion for this case - #5267.

[presian]

Hi @miherlosev
Unfortunately, I am not able to share it. It is not publicly accessible. But do not worry about this. This project is very complicated and generates a lot of communication between opened windows so it could be anything in our source code. It is just one big mess.

Thank you for the created suggestion. It will be very helpful to me.

[Farfurix]

@presian

Hello,

If you can reproduce this issue in a small project, please share it with us. It will help us to get more details about your your scenario.

Also, you can share your project (or some URL with credentials) via support@devexpress.com. In this case, please note that our policy prevents us from accessing a customer’s internal resources without prior written approval from the entity that owns the server/web resource. If you want us to research the problem further, we’ll need access to the server/web resource. Please ask the website owner to send us (support@devexpress.com) a written confirmation. It must permit DevExpress personnel to remotely access the website and its internal resources for research/testing/and debugging purposes.

[presian]

Hi @Farfurix

Unfortunately, the organization that I am working for won't allow access to their products from outside the organization.

I have some progress though. I found out that the newly opened window becomes a current window but its id is just the same as the parent window. That way the parent window is no more accessible.

I played with some client js (t.eval) and it turned out that after the second window is opened window.location.href returns the child's window URL. Through the window.opener I get the parent window. But paretnWindow.location.href returns the full URL like http://172.16.25.238:62629/PW!IBHA0M*OrvxTsefh/{the real paretnWindowUrl}.

But at the same time t.maximizeWindow() doesn't work on the child window.

I think that for whatever reason the child window hijacks the parent context but not entirely.

I know that this probably is not enough to help you guys but this all that I have.

Parent:

Child:

[Ogurecher]

@presian, Thank you for the information. We will take it into account.

[presian]

Hi all,
I finally managed to locate what causes this behavior (same id for parent and child window). The problem occurs when the new window is opened through some js and initially the URL is an empty string like following:

const secondPageWindow = window.open('', '_blank', 'location=yes,height=570,width=520,scrollbars=yes,status=yes');

and immediately after that, the URL of the newly opened window is changed like following:

secondPageWindow.location.href = 'http://localhost:4200/second-page';

As a result, the child window has the same id as the parent.

As far as I understood this code guarantees that the new window will be a new tab instead of a separate window. I found the following comment above that piece of code:
//this way, it opens in a new tab???if the url is directly specified it opens a new window

I have made a repository with a simple Angular project that mimics that behavior:
TestcafeThreeWindowsExample

[Ogurecher]

Hello @presian,
Thank you for your report. I've reproduced the issue and created a separate thread.
We'll research the issue and update that thread once it's fixed.

[miherlosev]

Folks

We are happy to announce that we released the mentioned feature ('Add the capability to perform testing in multiple browser windows') in testcafe@1.11.0.
See the documentation in the following help topic: https://devexpress.github.io/testcafe/documentation/guides/advanced-guides/multiple-browser-windows.html.