Security News
Research
Data Theft Repackaged: A Case Study in Malicious Wrapper Packages on npm
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
cypress-fail-fast
Advanced tools
The cypress-fail-fast npm package is a plugin for Cypress that allows you to stop the test suite execution as soon as a test fails. This can save time during development and continuous integration by not running tests that are likely to fail due to a known issue.
Stop test execution on first failure
This feature allows you to stop the entire test suite execution as soon as a single test fails. You need to add the plugin to your Cypress configuration file.
module.exports = (on, config) => {
require('cypress-fail-fast/plugin')(on, config);
};
Command-line option to enable/disable fail-fast
You can enable or disable the fail-fast functionality via command-line options. This is useful for different environments or stages in your CI/CD pipeline.
cypress run --env failFast=true
Fail-fast configuration in cypress.json
You can also configure the fail-fast option directly in your cypress.json file, making it easy to manage the setting across different projects or environments.
{
"env": {
"failFast": true
}
}
Enables fail fast in Cypress, skipping the rest of tests on first failure.
It can be configured to skip all remaining tests in current spec file, in current run, or even in parallel runs.
Add the plugin to devDependencies
npm i --save-dev cypress-fail-fast
Now, depending on your Cypress version, use one of the next methods:
Inside cypress.config.ts
file:
import cypressFailFast from "cypress-fail-fast/plugin";
export default defineConfig({
e2e: {
setupNodeEvents(on, config) {
cypressFailFast(on, config);
},
},
});
In case you are using JavaScript, you may explicit the file extension in some cases:
import cypressFailFast from "cypress-fail-fast/plugin.js"
Note: This example shows how to install the plugin for e2e
testing type. Read Cypress configuration docs for further info.
At the top of your support file (usually cypress/support/e2e.js
for e2e
testing type)
import "cypress-fail-fast";
Inside cypress/plugins/index.js
:
module.exports = (on, config) => {
require("cypress-fail-fast/plugin")(on, config);
return config;
};
At the top of cypress/support/index.js
:
import "cypress-fail-fast";
From now, if one test fail after its last retry, the rest of tests will be skipped:
spec
strategy does not work in headed mode, because for Cypress events it is like running a single spec, so all remaining tests will be skipped.FAIL_FAST_STRATEGY
: 'spec'|'run'|'parallel'
spec
, only remaining tests in current spec file are skipped. This mode only works in "headless" mode.run
, all remaining tests in all spec files are skipped (default value).parallel
to provide your own callbacks allowing to notify from one run to the others when remaining tests should be skipped.FAIL_FAST_ENABLED
: boolean = true
Allows disabling the "fail-fast" feature globally, but it could be still enabled for specific tests or describes using configuration by test.FAIL_FAST_PLUGIN
: boolean = true
If false
, it disables the "fail-fast" feature totally, ignoring even plugin configurations by test.FAIL_FAST_BAIL
: Number = 1
Enable the skip mode immediately upon n number of failing test suite. Defaults to 1.CYPRESS_FAIL_FAST_PLUGIN=false npm run cypress
or set the "env" key in the cypress.json
configuration file:
{
"env":
{
"FAIL_FAST_STRATEGY": "run",
"FAIL_FAST_ENABLED": true,
"FAIL_FAST_BAIL": 2,
}
}
If you want to configure the plugin on a specific test, you can set this by using the failFast
property in test configuration. The plugin allows next config values:
failFast
: Configuration for the plugin, containing any of next properties:
enabled
: Indicates wheter a failure of the current test or children tests (if configuration is applied to a suite) should produce to skip the rest of tests or not. Note that the value defined in this property has priority over the value of the environment variable CYPRESS_FAIL_FAST_ENABLED
(but not over CYPRESS_FAIL_FAST_PLUGIN
, which disables the plugin totally).In the next example, tests are configured to "fail-fast" only in case the test with the "sanity test" description fails. If any of the other tests fails, "fail-fast" will not be applied.
describe("All tests", {
failFast: {
enabled: false, // Children tests and describes will inherit this configuration
},
}, () => {
it("sanity test", {
failFast: {
enabled: true, // Overwrite configuration defined in parents
},
}, () => {
// Will skip the rest of tests if this one fails
expect(true).to.be.true;
});
it("second test",() => {
// Will continue executing tests if this one fails
expect(true).to.be.true;
});
});
Set the FAIL_FAST_ENABLED
key in the cypress.json
configuration file:
{
"env":
{
"FAIL_FAST_ENABLED": false
}
}
Enable "fail-fast" in those specs you want using configurations by test:
describe("All tests", { failFast: { enabled: true } }, () => {
// If any test in this describe fails, the rest of tests and specs will be skipped
});
Set the FAIL_FAST_PLUGIN
key in your local cypress.env.json
configuration file:
{
"env":
{
"FAIL_FAST_PLUGIN": false
}
}
The plugin configuration supports defining two callbacks that, used in combination, allow to skip tests in one run when other run starts skipping tests also. Where, or how do you store the "flag" that allows to communicate your runs is in your hands, the plugin does not care about it.
To implement it, the plugin can receive an object with extra configuration as third argument when it is registered in the cypress/plugins/index.js
file:
parallelCallbacks
: Object containing next properties:
onCancel
: function()
This callback is executed on first test failure that produces the plugin starts skipping tests.isCancelled
: function(): boolean
If this callback returns true
, the plugin skips remaining tests.These callbacks are executed only when the environment variable FAIL_FAST_STRATEGY
is set to parallel
.
Here is an example of configuration that would skip tests on many parallel runs when one of them starts skipping tests. It would only work if all parallel runs have access to the folder where the isCancelled
flag is being stored as a file (easy to achieve if all of your parallel runs are being executed on Docker images on a same machine, for example). Note that this is only an example, you could also implement it storing the flag in a REST API, etc.
// Example valid for Cypress versions lower than 10. Use config file on Cypress 10
const fs = require("fs");
const path = require("path");
// Flag file is stored in the /cypress folder
const isCancelledFlagFile = path.resolve(__dirname, "..", ".run-is-cancelled");
module.exports = (on, config) => {
require("cypress-fail-fast/plugin")(on, config, {
parallelCallbacks: {
onCancel: () => {
// Create flag file when the plugin starts skipping tests
fs.writeFileSync(isCancelledFlagFile, "");
},
isCancelled: () => {
// If any other run has created the file, start skipping tests
return fs.existsSync(isCancelledFlagFile);
},
},
});
return config;
};
Note that this example requires to remove the created file when all of the runs have finished, or tests will always be skipped whenever any run starts again. So, the FAIL_FAST_STRATEGY
environment variable should be set to parallel
only in CI pipelines where the workspace is cleaned on finish, for example.
If you are using TypeScript in the Cypress plugins file, this plugin includes TypeScript declarations and can be imported like the following:
import cypressFailFast = require("cypress-fail-fast/plugin");
export default (on: Cypress.PluginEvents, config: Cypress.PluginConfigOptions): Cypress.PluginConfigOptions => {
cypressFailFast(on, config);
return config;
};
Note: The example above is only valid for Cypress versions lower than 10. Use the configuration file in Cypress 10.
To ensure the plugin stability, the current major version is being tested with Cypress major versions 9.x, 10.x, 11.x, 12.x and 13.x, and new releases will be published for each new Cypress minor or major releases, updating the E2E tests.
Minor versions used in the E2E tests can be checked in the devDependencies
of the package.json
files of the E2E tests:
Even when current major version may work with previous Cypress versions, it is not currently tested, so, to be sure it works you should use:
cypress-fail-fast
7.0.xcypress-fail-fast
6.xcypress-fail-fast
5.xcypress-fail-fast
<= 4.xIf you find any issue for a specific Cypress version, please report it at https://github.com/javierbrea/cypress-fail-fast/issues.
This plugin has been developed based on the solutions proposed by the community on this Cypress issue, so thanks to all! I hope this plugin can be deprecated soon, as soon as the Cypress team adds native support for this feature. 😃
Contributors are welcome. Please read the contributing guidelines and code of conduct.
MIT, see LICENSE for details.
[7.1.1] - 2024-08-04
shouldSkip
flag to true
when a before hook fails in Cypress 13.FAQs
Skip the rest of Cypress tests on first failure
The npm package cypress-fail-fast receives a total of 132,856 weekly downloads. As such, cypress-fail-fast popularity was classified as popular.
We found that cypress-fail-fast demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.