---
title: Test Impact Analysis for JavaScript and TypeScript
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Test Optimization in Datadog > Test Impact Analysis > Configure Test
  Impact Analysis > Test Impact Analysis for JavaScript and TypeScript
---

# Test Impact Analysis for JavaScript and TypeScript

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site). ().
{% /alert %}

{% /callout %}

## Overview{% #overview %}

Test Impact Analysis for JavaScript skips entire *test suites* (test files) rather than individual tests.

## Compatibility{% #compatibility %}

Test Impact Analysis is only supported in the following versions and testing frameworks:

- `jest>=24.8.0`
  - From `dd-trace>=4.17.0` or `dd-trace>=3.38.0`.
  - Only `jest-circus/runner` is supported as `testRunner`.
  - Only `jsdom` and `node` are supported as test environments.
- `mocha>=5.2.0`
  - From `dd-trace>=4.17.0` or `dd-trace>=3.38.0`.
  - Run mocha with [`nyc`](https://www.npmjs.com/package/nyc) to enable code coverage.
- `cucumber-js>=7.0.0`
  - From `dd-trace>=4.17.0` or `dd-trace>=3.38.0`.
  - Run cucumber-js with [`nyc`](https://www.npmjs.com/package/nyc) to enable code coverage.
- `cypress>=6.7.0`
  - From `dd-trace>=4.17.0` or `dd-trace>=3.38.0`.
  - Instrument your web application with [code coverage](https://docs.cypress.io/guides/tooling/code-coverage#Instrumenting-code).

## Setup{% #setup %}

### Test Optimization{% #test-optimization %}

Prior to setting up Test Impact Analysis, set up [Test Optimization for JavaScript and TypeScript](https://docs.datadoghq.com/continuous_integration/tests/javascript). If you are reporting data through the Agent, use v6.40 and later or v7.40 and later.

### Activate Test Impact Analysis for the test service{% #activate-test-impact-analysis-for-the-test-service %}

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](https://app.datadoghq.com/ci/settings/test-service) page.

## Run tests with Test Impact Analysis enabled{% #run-tests-with-test-impact-analysis-enabled %}

{% tab title="On-Premises CI Provider (Datadog Agent)" %}
After completing setup, run your tests as you normally do:

```shell
NODE_OPTIONS="-r dd-trace/ci/init" DD_ENV=ci DD_SERVICE=my-javascript-app yarn test
```

{% /tab %}

{% tab title="Cloud CI provider (Agentless)" %}
After completing setup, run your tests as you normally do:

```shell
NODE_OPTIONS="-r dd-trace/ci/init" DD_ENV=ci DD_SERVICE=my-javascript-app DD_CIVISIBILITY_AGENTLESS_ENABLED=true DD_API_KEY=$DD_API_KEY yarn test
```

{% /tab %}

### Cypress{% #cypress %}

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](https://docs.cypress.io/guides/tooling/code-coverage#Instrumenting-code).

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.

## Inconsistent test durations{% #inconsistent-test-durations %}

In some frameworks, such as `jest`, there are cache mechanisms that make tests faster after other tests have run (see [jest cache](https://jestjs.io/docs/cli#--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.

## Disabling skipping for specific tests{% #disabling-skipping-for-specific-tests %}

You can override the Test Impact Analysis behavior and prevent specific tests from being skipped. These tests are referred to as unskippable tests.

### Why make tests unskippable?{% #why-make-tests-unskippable %}

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.

### Marking tests as unskippable{% #marking-tests-as-unskippable %}

{% tab title="Jest/Mocha/Cypress" %}
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`](https://jestjs.io/docs/configuration#testenvironmentoptions-object).

```javascript
/**
 * @datadog {"unskippable": true}
 */

describe('context', () => {
  it('can sum', () => {
    expect(1 + 2).to.equal(3)
  })
})
```

{% /tab %}

{% tab title="Cucumber" %}
You can use the `@datadog:unskippable` [tag](https://cucumber.io/docs/cucumber/api/?lang=javascript#tags) 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"
```

{% /tab %}

### Examples of tests that should be unskippable{% #examples-of-tests-that-should-be-unskippable %}

This section shows some examples of tests that should be marked as unskippable.

#### Tests that depend on fixtures{% #tests-that-depend-on-fixtures %}

```javascript
/**
 * 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}
 */
import processPayload from './process-payload';
import payload from './fixtures/payload';

it('can process payload', () => {
    expect(processPayload(payload)).toMatchSnapshot();
});
```

#### Tests that communicate with external services{% #tests-that-communicate-with-external-services %}

```javascript
/**
 * 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();
        });
});
```

```gdscript3
# Same way as above we're requesting an external service

@datadog:unskippable
Feature: Process the payload
  Scenario: Server responds correctly
    When the server responds correctly
    Then I should have received "value"
```

## Further Reading{% #further-reading %}

- [Explore Test Results and Performance](https://docs.datadoghq.com/continuous_integration/tests)
- [Troubleshooting CI Visibility](https://docs.datadoghq.com/continuous_integration/troubleshooting/)