testcafe icon indicating copy to clipboard operation
testcafe copied to clipboard

Testcafe slow compile time with big project

Open Makavelic opened this issue 1 year ago • 1 comments

What is your Scenario?

This relates to issue 4054

The provided solution does not work for our repo. Our page classes more often than not take a mandatory constructor for re-use purposes in order to act as the base selector. For example, we use checkboxes everywhere in the product but in order to select the correct one we first need to scope it to a container selector.

Additionally, page classes are often the ones actually constructing the new pages (because they often derive the selector required to pass into the constructor). Think something like async clickButton: Promise<SomeNewPage>. Because of this dynamic nature, we can't simply do something like export default new PageClass();

Based on my debugging the long compile time occurs here:

node_modules\testcafe\lib\compiler\index.js -> _compileTestFiles.

The browser to run the tests only opens once this compile step is done.

I have no idea how to debug further to figure out how to optimize this or whether anything is configurable.

Our repo has over 2000 tests and 500 page classes and continues to grow. Currently our tests can take any where from 30 seconds to 3 minutes just to open the browser (depending on machine specs but also can sometimes vary by 30 seconds between runs on the same machine some reason).

Is there anyway to create some sort of cache between test runs so we don't need to wait every single time we run a test?

Also just a FYI I am aware of this guide: https://testcafe.io/documentation/402963/guides/best-practices/speed-up-test-execution#optimize-your-page-model

but I don't think its realistic for our use case. We can't have tests that test pages in isolation - we're testing e2e and need to navigate from page to page. As a result, our test files will always need multiple page objects.

What is the Current behavior?

Tests take too long to open the browser (due to _compileTestFiles)

What is the Expected behavior?

_compileTestFiles should be faster

What is the public URL of the test page? (attach your complete example)

See https://github.com/DevExpress/testcafe/issues/4054

What is your TestCafe test code?

See https://github.com/DevExpress/testcafe/issues/4054

Your complete configuration file

No response

Your complete test report

No response

Screenshots

No response

Steps to Reproduce

  1. Run tests
  2. Compile time takes long

TestCafe version

3.5.0

Node.js version

18.18.2

Command-line arguments

testcafe 'chrome' 'path\testName.ts' '-c' '1' '--test' 'test1'

Browser name(s) and version(s)

No response

Platform(s) and version(s)

No response

Other

No response

Makavelic avatar Feb 07 '24 16:02 Makavelic

Hello @Makavelic,

You can use the --esm option to run the test. This should reduce the load on the compiler.

we're testing e2e and need to navigate from page to page. As a result, our test files will always need multiple page objects.

Also, could you please share a project with several examples that cover the usage scenario you described? This will allow the TestCafe team to research it and look for a workaround.

PavelMor25 avatar Feb 13 '24 09:02 PavelMor25

Might be a bit off-topic, but for me it's a similar case of E2E testing with multiple pages. I am using the page model for a better structure of my code (selector re-use, organisational benefits, etc), even though I understand from the documentation that I cannot expect speed benefits by doing so.

I cannot share a project, but basically it's a large documents library with tests that start on the homepage (homepage page model), login here, go to the search page (search page model), then do all kinds of search queries and eventually end up clicking a document (document page model).

di5ko avatar Feb 20 '24 14:02 di5ko

Hello @Makavelic,

You can use the --esm option to run the test. This should reduce the load on the compiler.

we're testing e2e and need to navigate from page to page. As a result, our test files will always need multiple page objects.

Also, could you please share a project with several examples that cover the usage scenario you described? This will allow the TestCafe team to research it and look for a workaround.

We are using typescript so --esm isn't an option, thanks for the suggestion though!

Our project is massive and needs to be closed so I can't share anything publicly unfortunately. Since I don't know what the actual problem is I don't know how to create a custom project to exhibit the problems we're seeing. If your team offers any kind of paid support for live sessions please let me know!

Makavelic avatar Feb 20 '24 16:02 Makavelic

You can create something similar to your project with some examples. As page you can use any public page. I need to know which techniques you used when you tested the project. Perhaps I can extend the provided project and investigate the issue further.

Regarding paid support for live sessions, we do not offer such support, but we are always here to assist.

PavelMor25 avatar Feb 23 '24 07:02 PavelMor25

This issue was automatically closed because there was no response to our request for more information from the original author. Currently, we don't have enough information to take action. Please reach out to us if you find the necessary information and are able to share it. We are also eager to know if you resolved the issue on your own and can share your findings with everyone.

github-actions[bot] avatar Mar 04 '24 07:03 github-actions[bot]