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

refactor(test): adjust sandbox folder location and simplify config logic #3493

Merged
merged 1 commit into from
May 1, 2020

Conversation

devoto13
Copy link
Collaborator

This is a bit bigger change, but modifications are related and I think it makes sense to land them all together.

The main change is in test/e2e/support/world.js file, where all important paths are defined:

  • workDir is the current working directory for the tested Karma process - test/e2e/support. Same as before.
  • sandboxDir moved from tmp/sandbox in the repository root to test/e2e/support/sandbox. Sandbox directory is reset before every scenario (see test/e2e/step_definitions/hooks.js) and this is where all generated files should be (hence change of paths in browser_console.feature). This also makes things cleaner as now all paths in the .feature files are relative to workDir.
  • configFile is path where Karma config file is generated. It no longer contains hash as it was not really needed. It may be re-introduced later if tests are run in parallel, but then it makes more sense to have it as a part of sandboxDir instead.
  • karmaExecutable is an absolute path to the Karma executable.

The change from __dirname + '/ to _resolve(' in two .feature files is to avoid having two different hacks to resolve absolute paths.

The last change in this file is to simplify config generation methods.

Remaining changes in test/e2e/step_definitions/core_steps.js are adapting steps to the above changes by removing bunch of boilerplate, which is no longer necessary.

@karmarunnerbot
Copy link
Member

Build karma 240 completed (commit d382ad4034 by @devoto13)

@karmarunnerbot
Copy link
Member

Build karma 239 completed (commit d382ad4034 by @devoto13)

test/e2e/support/world.js Outdated Show resolved Hide resolved
This is a bit bigger change, but modifications are closely related and I think it makes sense to land them all together.

The main change is in test/e2e/support/world.js file, where all important paths are defined:

- `workDir` is the current working directory for the tested Karma process - `test/e2e/support`. Same as before.
- `sandboxDir` moved from `tmp/sandbox` in the repository root to `test/e2e/support/sandbox`. Sandbox directory is reset before every scenario (see `test/e2e/step_definitions/hooks.js`) and this is where all generated files should be (hence change of paths in `browser_console.feature`). This also makes things cleaner as now all paths in the .feature files are relative to `workDir`.
- `configFile` is path where Karma config file is generated. It no longer contains hash as it was not really needed. It may be re-introduced later if tests are run in parallel, but then it makes more sense to have it as a part of `sandboxDir` instead.
- `karmaExecutable` is an absolute path to the Karma executable.

The change from `__dirname + '/` to `_resolve('` in two .feature files is to avoid having two different hacks to resolve absolute paths.

The last change in this file is to simplify config generation methods.

Remaining changes in `test/e2e/step_definitions/core_steps.js` are adapting steps to the above changes by removing bunch of boilerplate, which is no longer necessary.
@karmarunnerbot
Copy link
Member

Build karma 241 completed (commit 22e67110db by @devoto13)

@karmarunnerbot
Copy link
Member

Build karma 240 completed (commit 22e67110db by @devoto13)

Copy link
Contributor

@johnjbarton johnjbarton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much better thanks!

@johnjbarton johnjbarton merged commit 0bd5c2b into karma-runner:master May 1, 2020
@devoto13 devoto13 deleted the e2e-paths branch May 1, 2020 15:28
@devoto13
Copy link
Collaborator Author

devoto13 commented May 1, 2020

@johnjbarton Have no idea why BrowserStack tests failed again... This change should not have affected anything in client tests. Do you have access to any logs or something in the BrowserStack UI?

https://travis-ci.org/github/karma-runner/karma/jobs/681994903#L716

@johnjbarton
Copy link
Contributor

This looks unrelated to your change. I restarted the job.

@karmarunnerbot
Copy link
Member

🎉 This PR is included in version 5.0.5 🎉

The release is available on:

Your semantic-release bot 📦🚀

anthony-redFox pushed a commit to anthony-redFox/karma that referenced this pull request May 16, 2023
…gic (karma-runner#3493)

This is a bit bigger change, but modifications are closely related and I think it makes sense to land them all together.

The main change is in test/e2e/support/world.js file, where all important paths are defined:

- `workDir` is the current working directory for the tested Karma process - `test/e2e/support`. Same as before.
- `sandboxDir` moved from `tmp/sandbox` in the repository root to `test/e2e/support/sandbox`. Sandbox directory is reset before every scenario (see `test/e2e/step_definitions/hooks.js`) and this is where all generated files should be (hence change of paths in `browser_console.feature`). This also makes things cleaner as now all paths in the .feature files are relative to `workDir`.
- `configFile` is path where Karma config file is generated. It no longer contains hash as it was not really needed. It may be re-introduced later if tests are run in parallel, but then it makes more sense to have it as a part of `sandboxDir` instead.
- `karmaExecutable` is an absolute path to the Karma executable.

The change from `__dirname + '/` to `_resolve('` in two .feature files is to avoid having two different hacks to resolve absolute paths.

The last change in this file is to simplify config generation methods.

Remaining changes in `test/e2e/step_definitions/core_steps.js` are adapting steps to the above changes by removing bunch of boilerplate, which is no longer necessary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants