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

Disconnect timeouts occurring for multiple executors - OK for single executor #16

Closed
1 of 3 tasks
jamesopti opened this issue Apr 10, 2018 · 4 comments
Closed
1 of 3 tasks

Comments

@jamesopti
Copy link

jamesopti commented Apr 10, 2018

  • 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',
    },
@jamesopti
Copy link
Author

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.

@joeljeske
Copy link
Owner

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.

@joeljeske
Copy link
Owner

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

@joeljeske
Copy link
Owner

Closing due to inactivity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants