Skip to content

Latest commit

 

History

History
87 lines (56 loc) · 8.14 KB

DEVELOPMENT.md

File metadata and controls

87 lines (56 loc) · 8.14 KB

Development

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

Setup

Developing on this project requires Java 1.8, and the Maven packaging system.

Testing

Prerequisite

  • DD_TEST_CLIENT_API_KEY: The Datadog API key to run integration tests against
  • DD_TEST_CLIENT_APP_KEY: The Datadog Application key to run integration tests against

IMPORTANT: Do not use production keys.

Commands

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.

Writing Tests

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.

CI Setup

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
Integration Tests IBM JDK 8 IBM JDK requires some special treatment in terms of TLS usage; it's currently impossible to use it to with cassettes because of a mockserver issue

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.