Cypress: Takes too long before starting the test execution

Created on 12 Mar 2019  路  21Comments  路  Source: cypress-io/cypress

Current behavior:

Cypress is taking too much time to initialize the cypress before starting the test actual execution.
Actual execution of test takes only ~8-10 seconds, but when I start test using CLI i.e. using

cypress run -- --spec "cypress/integration/specname" --browser chrome

it will take around 30 seconds before it even starts the chrome.

Currently I'm working on windows 10, I have seen many tutorials and they seemed fast on mac OS. Is it in any way OS dependent when it comes to performance? especially, when you are running test through CLI.

Desired behavior:

It should only take few seconds if not zero, before it starts test execution

Steps to reproduce:

  1. First of all I have configured my project in order to write the test cases in typescript.
  2. My Spec file,
describe('My First Cypress Test', () => {
    it('Not much', () => {
        cy.visit('https://www.google.co.in/');
    });
});
  1. Now you need to run the code using command,
cypress run -- --spec "cypress/integration/specname" --browser chrome

or

npm run cypress:run -- --spec "cypress/integration/specname" --browser chrome

Versions

Windows: 10 Enterprise
this is my package.json

{
  "name": "cypress-spike",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "cypress:run": "./node_modules/.bin/cypress run",
    "cypress:open": "./node_modules/.bin/cypress open",
    "test-junit": "cypress run --reporter junit --reporter-options 'mochaFile=junit-results/my-test-output.xml'",
    "test-multiple": "cypress run --reporter mocha-multi-reporters --reporter-options configFile=config.json",
    "delete:reports": "rm cypress/results/* || true",
    "prereport": "npm run delete:reports"
  },
  "dependencies": {},
  "devDependencies": {
    "@cypress/webpack-preprocessor": "^4.0.3",
    "@types/node": "^11.9.4",
    "cypress": "^3.1.5",
    "cypress-xpath": "^1.3.0",
    "mocha": "^6.0.1",
    "mocha-junit-reporter": "^1.18.0",
    "mocha-multi-reporters": "^1.1.7",
    "mochawesome": "^3.1.1",
    "ts-loader": "^5.3.3",
    "typescript": "^3.3.3",
    "webpack": "^4.29.5"
  },
  "author": "",
  "license": "ISC"
}

Thanks in advance

Most helpful comment

Okay even that much time is enough for me... Mine is taking like forever

All 21 comments

I wonder if this startup time is due to transpiling and watching a lot of files for some reason

@bahmutov is it because I configured it, so that I can use typescript? and which files are you talking about? I merely added any extra files apart from the name.spec.ts in integration folder

On my win7 machine (everything running from SSD), from npx cypress run to first display of (Run starting) it takes:

  • ~9s for cypress-test-tiny (1 empty spec)
  • ~13s for a project of 18 specs of moderate sizes each

Okay even that much time is enough for me... Mine is taking like forever

I'm still seeing this, any progress made here? Discoveries on what the cause was? We're using both OSX and Alpine Linux builds and seeing the same behavior.

Hello, facing the same issue, CLI takes atleast 10 seconds to start the cypress run. I'm using Cypress.json to pass the url still this happens. I am on windows. Any update please ? anyone..

Same issue here I'm on OSX. Cypress 3.4.1

You might get a better idea of what's causing the slowdown by enabling debug logs.

set the env var DEBUG=cypress*

Windows:

set DEBUG=cypress*
npm run cypress:run

OSX/Linux: DEBUG=cypress* npm run cypress:run

can someone from the cypress team like @jennifer-shehane please shed some light on why it takes that long? it adds up and blows out our test times by almost double the total time, and that's even on a lightning fast local development computer.

Same issue for me... It takes nearly 1 minute for tests to start on my machine ("waiting for localhost").
Using the Cypress debug feature, here the trace I got (only the operations that takes more than 1 sec):

cypress:browserify received user options: { browserifyOptions: { extensions: [ '.js', '.jsx', '.coffee' ], transform: [ [Function: transform], [Array], [Array] ], plugin: [] }, watchifyOptions: { ignoreWatch: [ '**/.git/**', '**/.nyc_output/**', '**/.sass-cache/**', '**/bower_components/**', '**/coverage/**', '**/node_modules/**' ] } } +13s

cypress:browserify finished bundling: C:\Users\me\AppData\Roaming\Cypress\cy\production\projects\myApp-255c3731241151d62bf2eff3120e6355\bundles\Specs\e2e\support\index.js +4s

cypress:server:controllers:spec sending spec { filePath: 'C:\\Users\\me\\AppData\\Roaming\\Cypress\\cy\\production\\projects\\myApp-255c3731241151d62bf2eff3120e6355\\bundles\\Specs\\e2e\\support\\index.js' } +49s

GET /__cypress/tests?p=Specs%5Ce2e%5Csupport%5Cindex.js-168 200 48882.590 ms - -
  cypress:server:events got request for event: get:project:status, { path: 'C:\\Dev\\env\\WebFrontEndApplications\\myApp' } +10s
  cypress:server:project get project status for client id undefined at path C:\Dev\env\WebFrontEndApplications\myApp +10s
  cypress:server:project no project id +1ms
  cypress:server:events sending ipc data { type: 'get:project:status', data: { id: 0.9356686012821931, data: { path: 'C:\\Dev\\env\\WebFrontEndApplications\\myApp', state: 'VALID' } } } +11ms
  cypress:browserify finished bundling: C:\Users\me\AppData\Roaming\Cypress\cy\production\projects\myApp-255c3731241151d62bf2eff3120e6355\bundles\Specs\e2e\specs\LogEntriesRetrieval.feature +12s
  cypress:server:plugins promise resolved for id 'inv2' with value C:\Users\me\AppData\Roaming\Cypress\cy\production\projects\myApp-255c3731241151d62bf2eff3120e6355\bundles\Specs\e2e\specs\LogEntriesRetrieval.feature +12s
  cypress:server:plugins promise resolved for id 'inv4' with value C:\Users\me\AppData\Roaming\Cypress\cy\production\projects\myApp-255c3731241151d62bf2eff3120e6355\bundles\Specs\e2e\specs\LogEntriesRetrieval.feature +1ms
  cypress:server:controllers:spec sending spec { filePath: 'C:\\Users\\me\\AppData\\Roaming\\Cypress\\cy\\production\\projects\\myApp-255c3731241151d62bf2eff3120e6355\\bundles\\Specs\\e2e\\specs\\LogEntriesRetrieval.feature' } +12s

cypress:server:server resolving visit { url: 'http://localhost:4201/', headers: { host: 'localhost:4201', connection: 'Upgrade', pragma: 'no-cache', 'cache-control': 'no-cache', 'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36', upgrade: 'websocket', origin: 'http://localhost:4201', 'sec-websocket-version': '13', 'accept-encoding': 'gzip, deflate, br', 'accept-language': 'en-US,en;q=0.9', 'sec-websocket-key': 'zpNyvOo+NzH/MdAB9cBsXQ==', 'sec-websocket-extensions': 'permessage-deflate; client_max_window_bits' }, options: { auth: null, failOnStatusCode: true, retryOnNetworkFailure: true, retryOnStatusCodeFailure: false, method: 'GET', body: null, headers: {}, timeout: 30000 } } +58s

cypress:server:request got cookies from browser { reqUrl: 'http://localhost:4201/', cookies: [] } +23s

cypress:network:agent addRequest called { isHttps: false, href: 'http://localhost:4201/' } +26s

cypress:network:connect beginning getAddress { hostname: 'localhost', port: '4201' } +26s

cypress:proxy:http Entering stage { stage: 'IncomingRequest' } +24s

cypress:proxy:http:request-middleware proxying request { req: { method: 'GET', proxiedUrl: 'http://localhost:4201/', headers: { host: 'localhost:4201', 'proxy-connection': 'keep-alive', 'upgrade-insecure-requests': '1', 'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36', accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9', 'sec-fetch-site': 'same-origin', 'sec-fetch-mode': 'nested-navigate',
referer: 'http://localhost:4201/__/', 'accept-encoding': 'gzip, deflate, br', 'accept-language': 'en-US,en;q=0.9', cookie: '__cypress.initial=true' } } } +24s

For my installation Cypress is now taking more than 80 seconds to start -- due to this I no longer use it as part of my workflow.

We need a full project provided to reproduce this. The information initially given, with the test code below is not enough to reproduce the issue.

describe('My First Cypress Test', () => {
  it('Not much', () => {
    cy.visit('https://www.google.co.in/');
  });
});

Here is a video of the test run that was originally given as an example. This run time in the video is expected.

We need a reproducible example

We cannot begin looking at the long load time without a completely reproducible example since we never see this problem.

This means there is very likely something specific to your project or setup that is slowing down the start time

  • webpack config?
  • typescript config?
  • some other file watching?
  • it involves the application under test?
  • proxy configuration?
  • some specific config in the configuration file?
  • etc
  • etc
  • etc

@jennifer-shehane That's not necessarily the case I have also tried running cypresses default tests with minimal node project skeleton on my windows machine. It just takes a lot of time. plus I tried running it on a Linux VM on my Windows Machine and it's blazing fast.

So not able to pinpoint the cause since I tried running it in every scenario. Unfortunately, It always take significant time while running on windows machine no matter what.

@jennifer-shehane Are you guys even working on this issue? This is really pain point for us as we wanted to use Cypress for our workflows. We are just waiting with NO response from your side

Note that this may be related to the nature of Windows (semi micro-kernel architecture, NTFS filesystem etc.), and ultimately unsolvable (although, it can be possibly improved to a degree --- but no idea how).

For my installation Cypress is now taking more than 80 seconds to start -- due to this I no longer use it as part of my workflow.

I found this may have been an issue with a package used by cypress-cucumber-preprocessor -- after updating to version 2.0+ tests begin running in about 12 seconds.

@StephRagazzi I notice you're also using Cucumber -- have you tried updating the preprocessor to version 2.0.1?

@StephRagazzi I notice you're also using Cucumber -- have you tried updating the preprocessor to version 2.0.1?

Yes! same for me, after upgrading to the latest version of the Cypress Cucumber package, it runs after 15 sec!!

We're working on giving more logging during the preprocessor step. Currently we hide stderr, but we're going to change that, so you'll be able to see webpack output for example. https://github.com/cypress-io/cypress/issues/5765

I had a problem like this. My startup times were around 40 seconds with not-very-many tests. Once the system started up it ran at a reasonable pace. I also had pretty bad stability issues where messing with the electron cypress window could cause the entire thing to crash.

The crux of the problem was that I was running Cypress itself (NOT THE TESTS) in a docker instance. This meant that the electron app Cypress was using my /dev/shm partition. Inside a docker this partition starts at 64 megabytes. My assumption is that the slowness to startup was because of Cypress-electron thrashing on that small space, being forced to use the real filesystem somehow (instead of in memory operations), and/or the smallness of the space causing some kind of exceptional problem where it fills up.

Once I mounted my external /dev/shm drive everything was 100% faster, and I haven't had a crash since then.

--volume=/dev/shm:/dev/shm

So if you're running Cypress in a Docker container make sure to increase your /dev/shm size by mounting it, or providing this command line option. No idea if 256 megabytes is enough, but this is the style of the command. --shm-size=256m

Perhaps Cypress could query the /dev/shm before it starts and print out an error or warning if the /dev/shm seems too small, or is the docker default.

Unfortunately we have to close this issue as there is not enough information to reproduce the problem. This does not mean that your issue is not happening - it just means that we do not have a path to move forward.

Please comment in this issue with a reproducible example (or some information we previously asked for) and we will consider reopening the issue.

Was this page helpful?
0 / 5 - 0 ratings