Validez les optimisations.

Ce produit n'est pas pris en charge par le site Datadog que vous avez sélectionné. ().

Cette page explique comment vérifier que les optimisations offertes par Test Optimization fonctionnent comme prévu. Le guide suppose que Test Optimization fonctionne déjà pour le dépôt en cours de validation, et il présente les étapes pour valider les optimisations pour un dépôt unique.

Exécutez ces validations uniquement dans une branche de fonctionnalité et ne les fusionnez pas dans votre branche par défaut ou principale.

Prérequis

Ces optimisations nécessitent une bibliothèque native prise en charge. Les téléchargements de fichiers XML JUnit ne sont pas pris en charge.

Option 1 : Valider localement avec un agent de codage

Rejoignez la Preview !

La validation par agent de codage local est en préversion et ne prend en charge que les projets JavaScript et TypeScript qui utilisent le package npm dd-trace.

À l’aide de l’invite fournie ci-dessous, demandez à un agent de codage local (un assistant IA capable d’inspecter et d’exécuter des commandes dans votre dépôt local) d’inspecter le package dd-trace installé et d’exécuter son runbook de validation Test Optimization. Cette méthode vérifie la compatibilité de la bibliothèque locale et la configuration CI. Elle vérifie également Early Flake Detection, Auto Test Retries et Flaky Test Management sans modifier les paramètres Datadog ni envoyer de résultats de validation à Datadog.

Le runbook se trouve à ci/runbook.md par rapport à la racine du package dd-trace installé.

Transmettez cette invite à votre agent de codage local :

Locate the installed dd-trace package, then read and execute its ci/runbook.md.

Cette méthode d’agent de codage est un check local qui n’exerce pas l’intégralité du workflow Datadog. Pour valider les workflows complets de prévention, d’atténuation et de remédiation, ou pour valider un langage autre que JavaScript ou TypeScript, utilisez l’Option 2, ci-dessous.

Option 2 : Valider le workflow complet

Ce workflow de validation vérifie le workflow Test Optimization complet dans Datadog. Effectuez ces validations (Prévention, Atténuation et Remédiation) dans l’ordre, car elles utilisent la même branche et le même test.

Étape 1 : Configurer la validation

Ce guide vous accompagne dans la réalisation de modifications locales et leur validation pour l’exécution de la CI. Il utilise un service de test et une branche dédiés afin de minimiser l’impact du workflow de validation sur les autres développeurs du dépôt.

  1. Configurez votre job de test CI pour définir DD_SERVICE avant l’exécution de la commande de test :

    export DD_SERVICE=validate-test-optimization

  2. Créez la branche de validation :

    git checkout -b validate-test-optimization

  3. Validez la modification de configuration CI qui définit DD_SERVICE, puis poussez la branche de validation pour déclencher une exécution de test :

    git add -A
git commit -m "Configure Test Optimization validation service"
git push -u origin validate-test-optimization

    Datadog détecte le service validate-test-optimization lorsque les tests sont signalés sous ce nom.

  4. Une fois l’intégration continue terminée, accédez aux paramètres des dépôts CI/CD et sélectionnez le dépôt que vous validez.

    Paramètres des dépôts CI/CD filtrés sur le dépôt en cours de validation

  5. Dans le coin supérieur droit du panneau coulissant, cliquez sur Test Service.

    Paramètres du dépôt avec le bouton Test Service dans le coin supérieur droit.

  6. Dans Test service overrides, sélectionnez le service validate-test-optimization.

    Remplacements du Test Service affichant les services de test détectés pour un dépôt.

  7. Configurez les remplacements de service suivants :

  8. Retournez aux paramètres du dépôt. Les Flaky Test Policies s’appliquent à chaque service de test du dépôt, et non à un service de test individuel. Pour limiter l’impact de la politique de validation, configurez-la uniquement pour la branche validate-test-optimization. Sous Flaky Test Policies, sur la tuile Quarantine, cliquez sur Configure.

    Paramètres du dépôt affichant le bouton Configurer pour la politique Quarantine flaky test.

  9. Activez la deuxième règle automatique : Si un Active flaky test échoue dans la branche validate-test-optimization, alors déplacez-le vers Quarantined.

    Politique Quarantine configurée pour les Active flaky tests sur la branche validate-test-optimization.

  10. Cliquez sur Save.

  11. Créez un New Flaky Test PR Gate et limitez-le au dépôt que vous validez.

Périmètre du New Flaky Test PR Gate.

Étape 2 : Prevention

Early Flake Detection détecte les nouveaux tests instables. New Flaky Test PR Gates les empêchent d’atteindre votre branche par défaut.

  1. Ajoutez un test qui échoue à la première tentative et réussit lors des nouvelles tentatives (en utilisant éventuellement le code fourni ci-dessous). Le nom du test doit contenir à la fois flaky et validation afin que vous puissiez l’identifier dans Datadog.

      const fs = require('node:fs');
const os = require('node:os');
const path = require('node:path');

test('flaky validation test', () => {
    const marker = path.join(os.tmpdir(), 'dd-validation-flaky');
    if (!fs.existsSync(marker)) {
        fs.writeFileSync(marker, '1');
        throw new Error('first attempt fails so Datadog can retry it');
    }
});

      from pathlib import Path
from tempfile import gettempdir


def test_flaky_validation_test():
    marker = Path(gettempdir()) / "dd-validation-flaky"
    if not marker.exists():
        marker.write_text("1")
        raise AssertionError("first attempt fails so Datadog can retry it")

      import static org.junit.jupiter.api.Assertions.fail;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import org.junit.jupiter.api.Test;

class ValidationFlakyTest {
    @Test
    void flakyValidationTest() throws IOException {
        Path marker = Paths.get(
            System.getProperty("java.io.tmpdir"),
            "dd-validation-flaky"
        );
        if (Files.notExists(marker)) {
            Files.write(marker, new byte[] { '1' });
            fail("first attempt fails so Datadog can retry it");
        }
    }
}

      require 'tmpdir'

RSpec.describe 'validation flaky tests' do
  it 'flaky validation test' do
    marker = File.join(Dir.tmpdir, 'dd-validation-flaky')
    unless File.exist?(marker)
      File.write(marker, '1')
      raise 'first attempt fails so Datadog can retry it'
    end
  end
end

      using System.IO;
using Xunit;

public class ValidationFlakyTests
{
    [Fact]
    public void FlakyValidationTest()
    {
        var marker = Path.Combine(Path.GetTempPath(), "dd-validation-flaky");
        if (!File.Exists(marker))
        {
            File.WriteAllText(marker, "1");
            throw new System.Exception("first attempt fails so Datadog can retry it");
        }
    }
}

      package validation

import (
    "errors"
    "os"
    "path/filepath"
    "testing"
)

func TestFlakyValidationTest(t *testing.T) {
    marker := filepath.Join(os.TempDir(), "dd-validation-flaky")
    if _, err := os.Stat(marker); errors.Is(err, os.ErrNotExist) {
        if writeErr := os.WriteFile(marker, []byte("1"), 0600); writeErr != nil {
            t.Fatal(writeErr)
        }
        t.Fatal("first attempt fails so Datadog can retry it")
    }
}

      import XCTest

final class ValidationFlakyTests: XCTestCase {
    func testFlakyValidationTest() throws {
        let marker = FileManager.default.temporaryDirectory
            .appendingPathComponent("dd-validation-flaky")
        if !FileManager.default.fileExists(atPath: marker.path) {
            try "1".write(to: marker, atomically: true, encoding: .utf8)
            XCTFail("first attempt fails so Datadog can retry it")
        }
    }
}

    • Commitez et poussez le test, puis ouvrez une pull request depuis la branche de validation :

      git add -A
git commit -m "Validate Test Optimization prevention"
git push origin validate-test-optimization

    • Attendez que la CI s’exécute. Early Flake Detection relance le nouveau test, et le New Flaky Test PR Gate évalue le résultat. Dans les checks GitHub de votre pull request, confirmez que le New Flaky Test PR Gate échoue :

      Check de la pull request GitHub échouant car un nouveau test instable est détecté

    • Cliquez sur le check GitHub en échec et confirmez que le test est inclus dans la liste des nouveaux tests instables :

      Vue détaillée de la porte de PR Datadog

    • Dans Test Runs, confirmez qu’Early Flake Detection a relancé le test et l’a détecté comme un nouveau test instable en utilisant cette requête, qui utilise les filtres suivants :

      • @test.name:*flaky*validation*
      • @git.branch:validate-test-optimization
      • @test.retry_reason:early_flake_detection
      • @test.test_management.is_new_flaky:true

    Étape 3 : Mitigation

    La mitigation est obtenue grâce à Auto Test Retries, Flaky Test Management et Flaky Test Policies. Ces fonctionnalités relancent les tests instables et mettent en quarantaine les échecs instables connus afin qu’ils ne bloquent pas l’intégration continue (CI).

    1. Dans le même test que celui ajouté pour la Prévention, remplacez le nom de fichier du marqueur dd-validation-flaky par dd-validation-flaky-mitigation. Ne renommez pas la fonction de test ou le cas de test. Le nouveau marqueur provoque un autre échec intentionnel lors de la première tentative. Le maintien du nom de test inchangé permet à Datadog d’associer l’exécution au test instable détecté lors de la Prévention. Aucune configuration Datadog supplémentaire n’est requise ; [Auto Test Retries] et [Flaky Test Management] prennent en charge le test lors de cette exécution. Mettez à jour le test pour votre langage :

        const fs = require('node:fs');
const os = require('node:os');
const path = require('node:path');

test('flaky validation test', () => {
    // Changed from dd-validation-flaky.
    const marker = path.join(os.tmpdir(), 'dd-validation-flaky-mitigation');
    if (!fs.existsSync(marker)) {
        fs.writeFileSync(marker, '1');
        throw new Error('first attempt fails so Datadog can retry it');
    }
});

        from pathlib import Path
from tempfile import gettempdir


def test_flaky_validation_test():
    # Changed from dd-validation-flaky.
    marker = Path(gettempdir()) / "dd-validation-flaky-mitigation"
    if not marker.exists():
        marker.write_text("1")
        raise AssertionError("first attempt fails so Datadog can retry it")

        import static org.junit.jupiter.api.Assertions.fail;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import org.junit.jupiter.api.Test;

class ValidationFlakyTest {
    @Test
    void flakyValidationTest() throws IOException {
        // Changed from dd-validation-flaky.
        Path marker = Paths.get(
            System.getProperty("java.io.tmpdir"),
            "dd-validation-flaky-mitigation"
        );
        if (Files.notExists(marker)) {
            Files.write(marker, new byte[] { '1' });
            fail("first attempt fails so Datadog can retry it");
        }
    }
}

        require 'tmpdir'

RSpec.describe 'validation flaky tests' do
  it 'flaky validation test' do
    # Changed from dd-validation-flaky.
    marker = File.join(Dir.tmpdir, 'dd-validation-flaky-mitigation')
    unless File.exist?(marker)
      File.write(marker, '1')
      raise 'first attempt fails so Datadog can retry it'
    end
  end
end

        using System.IO;
using Xunit;

public class ValidationFlakyTests
{
    [Fact]
    public void FlakyValidationTest()
    {
        // Changed from dd-validation-flaky.
        var marker = Path.Combine(Path.GetTempPath(), "dd-validation-flaky-mitigation");
        if (!File.Exists(marker))
        {
            File.WriteAllText(marker, "1");
            throw new System.Exception("first attempt fails so Datadog can retry it");
        }
    }
}

        package validation

import (
    "errors"
    "os"
    "path/filepath"
    "testing"
)

func TestFlakyValidationTest(t *testing.T) {
    // Changed from dd-validation-flaky.
    marker := filepath.Join(os.TempDir(), "dd-validation-flaky-mitigation")
    if _, err := os.Stat(marker); errors.Is(err, os.ErrNotExist) {
        if writeErr := os.WriteFile(marker, []byte("1"), 0600); writeErr != nil {
            t.Fatal(writeErr)
        }
        t.Fatal("first attempt fails so Datadog can retry it")
    }
}

        import XCTest

final class ValidationFlakyTests: XCTestCase {
    func testFlakyValidationTest() throws {
        // Changed from dd-validation-flaky.
        let marker = FileManager.default.temporaryDirectory
            .appendingPathComponent("dd-validation-flaky-mitigation")
        if !FileManager.default.fileExists(atPath: marker.path) {
            try "1".write(to: marker, atomically: true, encoding: .utf8)
            XCTFail("first attempt fails so Datadog can retry it")
        }
    }
}

      • Commitez et poussez la modification sur la même branche :

        git add -A
git commit -m "Validate Test Optimization mitigation"
git push origin validate-test-optimization

      • Attendez l’exécution de l’intégration continue (CI), puis confirmez les résultats suivants :

        • Dans Test Runs, [Auto Test Retries] relance le test après son premier échec, et le test réussit lors de la nouvelle tentative. Utilisez cette requête, avec les filtres suivants :
          • @test.name:*flaky*validation*
          • @git.branch:validate-test-optimization
          • @test.retry_reason:auto_test_retry
        • Dans Flaky Test Management, le test apparaît comme QUARANTINED. Ses échecs ne bloquent plus le job de test. Utilisez cette requête, avec les filtres suivants :
          • @test.name:*flaky*validation*
          • first_flaked_branch:validate-test-optimization
          • flaky_test_state:quarantined

      Étape 4 : Remediation

      Test Optimization aide à remédier aux flaky tests grâce à Attempt to Fix et aux Bits AI-powered flaky test fixes. Cette section valide le workflow Attempt to Fix en corrigeant le même test utilisé pour Prevention et Mitigation.

      1. Dans Flaky Test Management, ouvrez le test de validation mis en quarantaine.

      2. Cliquez sur Actions, sélectionnez Link commit to fix et copiez la clé générée (elle commence par DD_).

        Modale Attempt to Fix.

      3. Remplacez le flaky test par la version réussie pour votre langage :

          test('flaky validation test', () => {
    expect(true).toBe(true);
});

          def test_flaky_validation_test():
    assert True

          @Test
void flakyValidationTest() {
    // intentionally empty - the test passes
}

          it 'flaky validation test' do
  expect(true).to be(true)
end

          [Fact]
public void FlakyValidationTest()
{
    Assert.True(true);
}

          func TestFlakyValidationTest(t *testing.T) {
}

          func testFlakyValidationTest() {
    XCTAssertTrue(true)
}

        • Commitez la correction avec la clé générée dans le corps du commit. Remplacez <YOUR_DD_KEY> par la clé que vous avez copiée :

          git add -A
git commit -m "Fix flaky validation test" -m "<YOUR_DD_KEY>"
git push origin validate-test-optimization

        • Attendez la fin de l’intégration continue (CI), puis confirmez les résultats suivants :

          • Dans Test Runs, [Attempt to Fix] a relancé le fix candidate, et chaque tentative a réussi. Utilisez cette requête, qui comporte les filtres suivants :
            • @test.name:*flaky*validation*
            • @git.branch:validate-test-optimization
            • @test.test_management.is_attempt_to_fix:true
          • Dans Flaky Test Management, le test est marqué Fix in progress. Utilisez cette requête, qui comporte les filtres suivants :
            • @test.name:*flaky*validation*
            • first_flaked_branch:validate-test-optimization
            • fix_in_progress:true

        Étape 5 : Nettoyage post-validation

        1. Fermez le pull request sans le fusionner.
        2. Supprimez la validate-test-optimizationbranche. La règle automatique Quarantine spécifique à la branche ne s’applique plus une fois la branche supprimée, et le service de validation dédié ne reçoit plus d’exécutions de test.
        3. Informez l’équipe propriétaire du dépôt que le New Flaky Test PR Gate reste actif pour l’ensemble du dépôt. La gate est non-blocking par défaut.
        4. Optionnellement, activez les fonctionnalités Test Optimization configurées pour le validate-test-optimization service au niveau du dépôt.

        Pour aller plus loin

        Documentation, liens et articles supplémentaires utiles:

        Configurez un New Flaky Test PR Gate.DOCUMENTATION more more En savoir plus sur Early Flake Detection.DOCUMENTATION more more En savoir plus sur Auto Test Retries.DOCUMENTATION more more En savoir plus sur la Gestion des tests irréguliersDOCUMENTATION more more