This page is not yet available in Spanish. We are working on its translation. If you have any questions or feedback about our current translation project, feel free to reach out to us!
You, or a user in your organization with the Intelligent Test Runner Activation (intelligent_test_runner_activation_write) permission, must activate Test Impact Analysis on the Test Service Settings page.
For Test Impact Analysis for Cypress to work, you must instrument your web application with code coverage. For more information about enabling code coverage, see the Cypress documentation.
To check that you’ve successfully enabled code coverage, navigate to your web app with Cypress and check the window.__coverage__ global variable. This is what dd-trace uses to collect code coverage for Test Impact Analysis.
In some frameworks, such as jest, there are cache mechanisms that make tests faster after other tests have run (see jest cache docs). If Test Impact Analysis is skipping all but a few test files, these suites might run slower than they usually do. This is because they run with a colder cache. Regardless of this, total execution time for your test command should still be reduced.
Test Impact Analysis uses code coverage data to determine whether or not tests should be skipped. In some cases, this data may not be sufficient to make this determination.
Examples include:
Tests that read data from text files
Tests that interact with APIs outside of the code being tested (such as remote REST APIs)
Designating tests as unskippable ensures that Test Impact Analysis runs them regardless of coverage data.
You can use the following docblock at the top of your test file to mark a suite as unskippable. This prevents any of the tests defined in the test file from being skipped by Test Impact Analysis. This is similar to jest’s testEnvironmentOptions.
You can use the @datadog:unskippabletag in your feature file to mark it as unskippable. This prevents any of the scenarios defined in the feature file from being skipped by Test Impact Analysis.
@datadog:unskippable
Feature: Greetings
Scenario: Say greetings
When the greeter says greetings
Then I should have heard "greetings"
/**
* We have a `payload.json` fixture file in `./fixtures/payload`
* that is processed by `processPayload` and put into a snapshot.
* Changes in `payload.json` do not affect the test code coverage but can
* make the test fail.
*//**
* @datadog {"unskippable": true}
*/importprocessPayloadfrom'./process-payload';importpayloadfrom'./fixtures/payload';it('can process payload',()=>{expect(processPayload(payload)).toMatchSnapshot();});
/**
* We query an external service running outside the context of
* the test.
* Changes in this external service do not affect the test code coverage
* but can make the test fail.
*//**
* @datadog {"unskippable": true}
*/it('can query data',(done)=>{fetch('https://www.external-service.com/path').then((res)=>res.json()).then((json)=>{expect(json.data[0]).toEqual('value');done();});});
# Same way as above we're requesting an external service@datadog:unskippableFeature:ProcessthepayloadScenario:ServerrespondscorrectlyWhentheserverrespondscorrectlyThenIshouldhavereceived"value"
