Test Impact Analysis for Go
This product is not supported for your selected
Datadog site. (
).
このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、
お気軽にご連絡ください。
Compatibility
Test Impact Analysis is only supported on orchestrion >= 0.9.4 + dd-trace-go >= 1.70.0.
Setup
Test Optimization
Prior to setting up Test Impact Analysis, set up Test Optimization for Go. If you are reporting data through the Agent, use v6.40 and later or v7.40 and later.
テストサービスの Test Impact Analysis を有効にする
あなた、またはあなたの組織で Intelligent Test Runner Activation (intelligent_test_runner_activation_write) 権限を持つユーザーが、テストサービス設定ページで Test Impact Analysis を有効にする必要があります。
Run tests with Test Impact Analysis enabled
After completing setup, run your tests by using go test with the following code coverage options:
orchestrion go test ./... -cover -covermode=count -coverpkg ./...
-cover: The Test Impact Analysis feature uses the built-in Go’s code coverage processor, so you need to enable code coverage collection in the go test command.
-covermode: must be either count or atomic. Because set is not supported, setting this value disables test impact analysis.
-coverpkg: the code coverage analysis for each test must be configured to apply in all package dependencies and not only for the package being tested. This way, if a dependency changes, you can track the test affected by this change. If you run the test command from the root of the project (where the go.mod file is), you can use the ./... wildcard. If not, you must manually list all package dependencies comma separated (pattern1, pattern2, pattern3, ...). For that, you could use the go list ./... command to get all the package names.
Having an incorrect -coverpkg value affects the ability of Test Impact Analysis to correctly track test coverage.
Disable 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?
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
Individual test case
Add the //dd:test.unskippable comment to your test case to mark it as unskippable.
import (
"testing"
)
//dd:test.unskippable
func TestMyCustomTest(t *testing.T) {
...
}
Test suite
Add the //dd:suite.unskippable comment at the begining of the file to mark it as unskippable.
If a suite is marked as unskippable, none of the test cases from that suite can be skipped by Test Impact Analysis.
import (
"testing"
)
//dd:suite.unskippable
func TestMyCustomTest(t *testing.T) {
...
}
func TestMyCustomTest2(t *testing.T) {
...
}
Further Reading
