1

Technology Used:

  • npm
  • jest
  • jest-puppeteer

If I run my tests one by one they individually pass

$ npm test test/file.to.test.js

...

Test Suites: 1 passed, 1 total
Tests:       6 passed, 6 total

However if I run my tests as a group then then errors are rampant

$ npm test

...

Test Suites: 6 failed, 6 total
Tests:       88 failed, 17 todo, 4 passed, 109 total

Question

My situation seems to be related to some kind of jest/puppeteer caching or chrome session sharing. Regargless, how can I debug this further?

Extra

While writing this question I found that using the argument --runInBand (from this answer) makes it so all tests pass but they are run sequentially which makes the tests take substantially longer - normally jest tests run in parallel.

Settings

package.json

"test": "set NODE_ENV=test && jest --runInBand --detectOpenHandles --forceExit",

jest-puppeteer.config.js

module.exports = {
    launch: {
        devtools: true, // allows for use of 'debugger;' in tests
        // executablePath: '/usr/bin/chromium-browser',
        headless: true,
        defaultViewport: {
            width: 1024,
            height: 768,
            //isMobile: true,
            //hasTouch: true,
        },
        ignoreDefaultArgs: ['--disable-extensions'],
        args: [
            '--enable-font-antialiasing',
            '--font-render-hinting=medium',
            '--disable-gpu',
            '--disable-dev-shm-usage',
            '--disable-setuid-sandbox',
            '--no-first-run',
            '--no-sandbox',
            '--no-zygote',
            '--single-process',

            "--renderer",
            "--no-service-autorun",
            "--no-experiments",
            "--no-default-browser-check",
            "--disable-extensions",
        ]
    },
    // server: {
    //     command: "npm run serve",
    //     port: 9000,
    //     launchTimeout: 180000
    // },
    browser: 'chromium',
    browserContext: 'default'
};
Jacksonkr
  • 31,583
  • 39
  • 180
  • 284
  • What are exact fail reasons? Why do you think that they could be caused by session sharing? I'd expect it could be how the server handles simultaneous requests. Were all of these chrome args added intentionally? – Estus Flask Jul 28 '20 at 20:13
  • @EstusFlask Answering questions in order: the fail reasons seem to be random at best; I'm more refferring to browser page state moreso than an actual browser session (poor word usage on my end); ; this project spans windows 10, Windows 10 WSL (ubuntu 18.04) OSX 10.14, 10.15 so this is all the args that work for every OS arrangement so far and NOT the args that break on any given OS. – Jacksonkr Jul 28 '20 at 20:32

1 Answers1

1

I read quite a bit about this and while I'm not exactly sure why this happens there are a couple of pretty seamless work arounds

--runInBand OR --maxConcurrency=2

Jacksonkr
  • 31,583
  • 39
  • 180
  • 284