This repository contains code that is autogenerated via the openapi-generator project.
As such, this repository should only contain development for adding or fixing tests, for improving development tooling and documentation
Developing on this project requires Java 1.8, and the Maven packaging system.
DD_TEST_CLIENT_API_KEY
: The Datadog API key to run integration tests againstDD_TEST_CLIENT_APP_KEY
: The Datadog Application key to run integration tests against
IMPORTANT: Do not use production keys.
This project contains both Integration and Unit tests.
Never run the test suite against an organization with production data.
The testing framework in this repository is JUnit, and can be executed via mvn test
Tests for a single class can be executed via:
mvn test -Dtest=TEST_CLASS_NAME
A single test method can be executed via:
mvn test -Dtest=TEST_CLASS_NAME#TEST_METHOD_NAME
By default integration tests use recorded API responses stored in cassettes. To record new API responses run the tests with RECORD=true
. To run integration tests against API without recording cassettes, run the tests with RECORD=none
.
IMPORTANT: When creating a PR that adds or updates a test, never commit generated code, only commit test files being updated and any updated cassettes.
Run test with DEBUG=true
to display api server calls being made during test execution. This can be useful during debug time.
When creating new entities/objects through the API as part of tests, make sure to assign result of getUniqueEntityName()
to at least one field of this object (e.g. title or name). This ensures uniqueness as well as trackability - in other words, if a CI run fails to clean up resources, we're able to track the entity to the CI run, as the unique name will contain CI run ID.
This project utilizes Azure Pipelines and Github Actions to perform CI test steps.
This repository contains a few types of tests:
Test Type | Description |
---|---|
Integration Tests | This runs real API calls to the Datadog API and runs assertions based on the responses. These tests requires a valid Datadog API and Application key. |
Integration Tests with Cassettes | This is the same set of tests from the Integration tests, however, these don't connect to the real Datadog api. Instead these tests playback a set of pre recorded real responses and run the assertions there. These types of tests don't require any secrets and allow for rapid iteration and quickly testing against a large OS/version matrix. |
Unit Tests | These tests utilize a set of fixture data to run assertions and don't connect to the Datadog API. These tests also don't require any secrets. |
We utilize a couple CI Providers to accomplish testing this project:
Test Type | CI Provider | Reason |
---|---|---|
Integration Tests | Azure Pipelines | We require Datadog credentials to access the real Datadog API environment, for this reason we use Azure Pipelines to control the triggering mechanism. |
Integration Tests with Cassettes | Github Actions | Adding an extended matrix to quickly test multiple OS and language versions is quick in Github Actions. |
Unit Tests | Azure Pipelines and Github Actions | Unit tests run fast with fixture data and are part of the regular test suite, as this is run on each test command invocation, its run in both providers. |
See the CI Provider
links above for the full matrix this project tests against. An explanation of the specific testing matrix entries follows:
Test Type | JDK | Reason |
---|---|---|
Integration Tests with Cassettes | AdoptOpenJDK 8 | We want to support Java 8 as the minimal version |
Integration Tests with Cassettes | Amazon Corretto 11 | This client is used in Datadog CloudFormation resources and we want to ensure it runs correctly on Amazon's JDK |
Integration Tests with Cassettes | Oracle JDK 14 | To guarantee compatibility with Oracle JDK |
Integration Tests | OpenJDK 8 | To ensure all integration tests pass on a canonical OpenJDK version 8 |
Note: IBM JDK 8 is not supported because it does not support PATCH
requests over HTTPS
.
You can skip GitHub action test execution by adding the ci/skip
label to your PR.
Tests running in Github Actions are those that require no secrets, to allow for PRs created from forks to run as expected. These are the unit tests and Integration tests with cassettes. These tests are run on each commit from a PR.
Tests running in Azure Pipelines are those that do require secrets, these being the Integration tests that connect to the Datadog API. These tests run only when a maintainer provides a Github comment on the PR after performing a review.