Este producto no es compatible con el sitio Datadog seleccionado. ().
Esta página aún no está disponible en español. Estamos trabajando en su traducción. Si tienes alguna pregunta o comentario sobre nuestro actual proyecto de traducción, no dudes en ponerte en contacto con nosotros.
For Ruby: use the datadog-ci gem version 1.31.0 or later.
For Python: use the ddtrace package version 4.11.0 or later and pytest.
For JavaScript: use the dd-trace package version 5.111.0 or later for v5 or v6.0.0 or later for v6, Node.js, and Jest.
Enable Test Impact Analysis for the test service when you want Test Parallelization to split only the tests affected by a code change.
Concepts
Runner
A program that runs tests. ddtest can run tests directly or write file lists for another runner.
CI node
One CI execution environment, such as a GitHub Actions job, CircleCI parallel container, Kubernetes pod, VM, or local machine.
Worker
A process started by ddtest to execute tests. One CI node can run one worker or multiple workers.
Plan
The generated .testoptimization/ directory. It contains the runnable test files, the selected parallelism, and per-node file lists used by ddtest run or another runner.
Selected parallelism
The CI node count or local worker count that ddtest chooses after estimating test file durations.
Install ddtest
Install the ddtest CLI in your CI job. Datadog publishes precompiled binaries in GitHub Releases.
These examples download the latest Linux AMD64 binary. For another operating system or architecture, select the corresponding asset from GitHub Releases.
Adopt ddtest in CI
Adopt Test Parallelization in four steps. First, add planning without changing how tests run. After validating the plan, replace the existing test command with ddtest, choose an execution mode, and measure the resulting CI savings.
Make these changes on a feature branch. Commit and push each CI configuration change, then review the resulting CI run before continuing.
1. Add test planning
After setting up dependencies and Test Optimization, add ddtest plan before your existing test step. Keep the existing test command in place during this step.
Choose the minimum and maximum parallelism for your CI environment. For example, the following values allow ddtest to choose between 1 and 8 CI nodes or local workers:
--platform identifies the language platform, and --framework identifies the test framework. Supported combinations include ruby with rspec or minitest, python with pytest, and javascript with jest. For all supported values and defaults, see Configuration.
Planning discovers tests, retrieves test duration and Test Impact Analysis data, and chooses a parallelism level. It does not execute tests. The generated .testoptimization/ directory contains the test files and splits selected for execution.
2. Inspect the plan
The following commands are one way to inspect the proposed runner count and test files in the CI logs:
# Show the number of runners selected by ddtest.cat .testoptimization/runner/parallel-runners.txt
# Count the test files selected for execution.wc -l .testoptimization/runner/test-files.txt
# Preview the first 20 test files to verify test discovery.sed -n '1,20p' .testoptimization/runner/test-files.txt
# Optional: List the per-runner split files to see how ddtest distributed the tests.find .testoptimization/runner/tests-split -maxdepth 1 -type f -print
Alternatively, download the .testoptimization/ directory as a CI artifact and open the files in your editor.
Confirm that test-files.txt contains a list of files to run. If Test Impact Analysis is enabled, files whose tests are all skipped are absent from the plan.
3. Replace the existing test command
After the plan contains the expected tests, replace the existing test command with:
bin/ddtest run \
--platform <PLATFORM> \
--framework <FRAMEWORK>
ddtest run reuses the plan generated earlier in the workflow. Choose how to run the selected splits based on your CI architecture.
Run workers on one CI node
On a single CI node, ddtest plan is optional. Run ddtest run directly, or run ddtest plan and ddtest run back-to-back in the same job if you want to inspect the plan first. The selected parallelism is the number of local worker processes that ddtest starts. The command does not require additional options.
Distribute tests across CI nodes
Run ddtest plan once in a planning job. Share the complete .testoptimization/ directory with the test jobs, and use the selected parallelism to define the size of your CI matrix. On each node, run:
In CI-node mode, ddtest uses one local worker by default. To start multiple workers in each CI node, set --ci-node-workers to a positive integer or ncpu.
The CI examples on this page show how to pass the generated plan and selected runner count between jobs.
4. Measure CI savings
After replacing the test command, confirm in the Test Optimization Explorer that the expected tests completed. Use the CI Visibility Explorer to compare test job durations and the number of test jobs between pipeline runs. If CI Visibility is not enabled, use the equivalent job metrics in your CI provider.
If all workers run on one CI node, parallel execution shortens the test stage without changing the number of CI nodes. If each worker runs on a separate CI node, use the runner count in parallel-runners.txt to size the CI matrix. Because Test Impact Analysis removes unaffected tests before ddtest selects the runner count, smaller changes can result in fewer CI nodes being started.
Use --max-parallelism to limit CI capacity. The planner accounts for the setup cost of each additional runner through --ci-job-overhead. For details about these settings, see Configuration.
Add .testoptimization/ to .gitignore. Generate a fresh plan for each CI workflow run, and share it only between jobs for the same source revision and execution environment. Run planning and tests from the same working directory. For details about the generated files, see Plan artifacts.
CI examples
Use the following examples as starting points for GitHub Actions and CircleCI.
Ruby
The plan job chooses the CI node count and emits a matrix. The test job downloads the .testoptimization/ artifact and runs only the files assigned to its matrix node.
name:CI with Test Parallelizationon:[push]env:DD_TEST_OPTIMIZATION_RUNNER_PLATFORM:rubyDD_TEST_OPTIMIZATION_RUNNER_FRAMEWORK:rspecDD_TEST_OPTIMIZATION_RUNNER_MIN_PARALLELISM:1DD_TEST_OPTIMIZATION_RUNNER_MAX_PARALLELISM:8jobs:dd_plan:runs-on:ubuntu-latestoutputs:matrix:${{ steps.dd_plan.outputs.matrix }}steps:- uses:actions/checkout@v4- name:Download ddtest binaryrun:| mkdir -p bin
gh release download --repo DataDog/ddtest --pattern "ddtest-linux-amd64" --dir bin
mv bin/ddtest-linux-amd64 bin/ddtest
chmod +x bin/ddtestenv:GH_TOKEN:${{ github.token }}- name:Setup Rubyuses:ruby/setup-ruby@v1with:bundler-cache:true- name:Configure Datadog Test Optimizationuses:datadog/test-visibility-github-action@v2with:languages:rubyapi_key:${{ secrets.DD_API_KEY }}site:datadoghq.com- id:dd_planname:Plan test executionrun:bin/ddtest plan- uses:actions/upload-artifact@v4with:name:dd-artifactspath:.testoptimizationinclude-hidden-files:truedd_test:runs-on:ubuntu-latestneeds:[dd_plan]strategy:fail-fast:falsematrix:${{ fromJson(needs.dd_plan.outputs.matrix) }}steps:- uses:actions/checkout@v4- name:Download ddtest binaryrun:| mkdir -p bin
gh release download --repo DataDog/ddtest --pattern "ddtest-linux-amd64" --dir bin
mv bin/ddtest-linux-amd64 bin/ddtest
chmod +x bin/ddtestenv:GH_TOKEN:${{ github.token }}- uses:actions/download-artifact@v4with:name:dd-artifactspath:.testoptimization- name:Setup Rubyuses:ruby/setup-ruby@v1with:bundler-cache:true- name:Configure Datadog Test Optimizationuses:datadog/test-visibility-github-action@v2with:languages:rubyapi_key:${{ secrets.DD_API_KEY }}site:datadoghq.com- name:Run testsrun:bin/ddtest run --ci-node ${{ matrix.ci_node_index }}
The setup workflow runs ddtest plan, stores .testoptimization/, and continues into a test workflow with the selected CI node count.
The plan job chooses the CI node count and emits a matrix. The test job downloads the .testoptimization/ artifact and runs only the files assigned to its matrix node.
Replace each language setup step with Node.js dependency installation:
- name:Setup Node.jsuses:actions/setup-node@v4with:node-version:"22"cache:npm- name:Install JavaScript dependenciesrun:npm ci
Configure Datadog Test Optimization for JavaScript:
- name:Configure Datadog Test Optimizationuses:datadog/test-visibility-github-action@v2with:languages:jsapi_key:${{ secrets.DD_API_KEY }}site:datadoghq.com
The ddtest plan and ddtest run --ci-node ${{ matrix.ci_node_index }} commands remain unchanged when the platform and framework are provided through the environment.
Use a Node.js image and set the runner environment in the plan job:
Keep the ddtest download, plan, cache, and continuation steps from the CircleCI workflow. In the test job, install dependencies, autoinstrument JavaScript, and pass the CircleCI node index to ddtest:
- run:name:Install JavaScript dependenciescommand:npm ci- test-optimization-circleci-orb/autoinstrument:languages:jssite:datadoghq.com- run:name:Run testscommand:| NODE_INDEX=${CIRCLE_NODE_INDEX:-0}
bin/ddtest run --platform javascript --framework jest --ci-node "${NODE_INDEX}"
`ddtest` prepends `NODE_OPTIONS=-r dd-trace/ci/init` for Jest worker processes, so the project dependencies installed before `ddtest plan` must include `dd-trace`.