joeljeske / karma-parallel

A Karma JS Framework to support sharding tests to run in parallel across multiple browsers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Disconnect timeouts occurring for multiple executors - OK for single executor

jamesopti opened this issue · comments

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

I'm seeing some odd behavior that I can't explain.

My tests pass fine with a single executor.

With multiple executors (and a test suite of 3000+ mocha tests), I'm noticing that sometimes the browsers hang and tests fail due to no the Karma no activity timeout.

I also noticed that when multiple chrome instances are running, the console output stalls until I focus one of them, then it begins spewing output again.

Is this a known issue? Or is there a Karma config that can prevent this?

  • What is the expected behavior?

Tests should pass in shared environment the same way as non-sharded.

  • Please tell us about your environment:
  • version: 0.2.5
  • Browser: [Chrome 57-65]
  • Language: [all]

And the relevant portion of the karma config:

  frameworks: ['parallel', 'mocha-debug', 'mocha'],

    parallelOptions: {
      executors: 2, // Defaults to cpu-count - 1
      shardStrategy: 'round-robin',
    },

I believe I'm onto the root cause here.

Sharding tests out across many executors means that any side effects that one test may be relying on from another (such as lazy loading a module) may not be guaranteed to have happened.

This re-enforces the correct practice of ensuring your test can run in isolation and dont rely on other imports.

Will confirm once I've fully investigated.

Interesting. Yes each test must setup its own dependencies.

I have had difficulty in migrating some of our projects to use this sharding mechanism because it reveals how some of our tests were initially written incorrectly. There is not much to do about it but try to enforce good habits on your team of always setting up your environment before each test and cleaning it up after.

@jamesopti Did you confirm that test independence was the root issue here?

Closing due to inactivity