Skip to content
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

TestCafe shouldn't start remote browsers before compiling tests #3219

Closed
link89 opened this issue Dec 13, 2018 · 3 comments
Closed

TestCafe shouldn't start remote browsers before compiling tests #3219

link89 opened this issue Dec 13, 2018 · 3 comments
Labels
STATE: Auto-locked An issue has been automatically locked by the Lock bot.

Comments

@link89
Copy link
Contributor

link89 commented Dec 13, 2018

What is your Test Scenario?

Using testcafe to run hundreds of tests on selenium-grid

What is the Current behavior?

selenium webdriver throw Timeout when cases compile didn't finish with BrowsersTimeout.
The reason for this error is clear. We are running our cases on selenium-grid for a long time. After upgrade to 0.23.x, we found that testcafe try to open browsers before cases compile. We will start a async task to sending heartbeats to selenium-grid to keep browsers open. But compile cases will block this tasks. It's ok when little files to compile, but it become a problem when number of cases is large. I hope we should follow the logic of version previous 0.23, which will open browsers after compile.

What is the Expected behavior?

open browser after compile success

What is your web application and your TestCafe test code?

Your website URL (or attach your complete example):

Your complete test code (or attach your test files):
 
Your complete test report:

Screenshots:

Steps to Reproduce:

  1. Go to my website ...
  2. Execute this command...
  3. See the error...

Your Environment details:

  • testcafe version: 0.23.2
@link89
Copy link
Contributor Author

link89 commented Dec 13, 2018

    async createRunnableConfiguration () {
        const reporterPlugins = this._getReporterPlugins();

        // NOTE: If a user forgot to specify a browser, but has specified a path to tests, the specified path will be
        // considered as the browser argument, and the tests path argument will have the predefined default value.
        // It's very ambiguous for the user, who might be confused by compilation errors from an unexpected test.
        // So, we need to retrieve the browser aliases and paths before tests compilation.
        const browserInfo = await this._getBrowserInfo();

        if (this._canUseParallelBootstrapping(browserInfo))
            return { reporterPlugins, ...await this._bootstrapParallel(browserInfo) };

        return { reporterPlugins, ...await this._bootstrapSequence(browserInfo) };
    }

I have found following comment explain why you make this choice. I don't think it a good reason to do it this way since it will waste browser resources when you running testcafe in CI/CD pipeline.

@link89
Copy link
Contributor Author

link89 commented Dec 13, 2018

Here is the trouble maker and a simple fix: https://github.com/DevExpress/testcafe/pull/3221/files

@AndreyBelym AndreyBelym changed the title open browser after compile success TestCafe shouldn't start remote browsers before compiling tests Dec 13, 2018
@lock
Copy link

lock bot commented Mar 27, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or feature requests. For TestCafe API, usage and configuration inquiries, we recommend asking them on StackOverflow.

@lock lock bot added the STATE: Auto-locked An issue has been automatically locked by the Lock bot. label Mar 27, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Mar 27, 2019
kirovboris pushed a commit to kirovboris/testcafe-phoenix that referenced this issue Dec 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
STATE: Auto-locked An issue has been automatically locked by the Lock bot.
Projects
None yet
Development

No branches or pull requests

1 participant