Valide Test Optimization

Documentación > Test Optimization en Datadog > Guías de Visibilidad de pruebas > Valide Test Optimization

Esta página explica cómo verificar que las optimizaciones ofrecidas por Test Optimization funcionen según lo previsto. La guía asume que Test Optimization ya funciona para el repositorio bajo validación, y muestra los pasos para validar las optimizaciones para un solo repositorio.

Ejecute estas validaciones solo en una rama de características y no las combine en su rama predeterminada o principal.

Requisitos previos

Estas optimizaciones requieren una biblioteca nativa compatible. Las cargas de archivos XML de JUnit no son compatibles.

Opción 1: Validar localmente con un agente de codificación

Utilizando el prompt proporcionado a continuación, pídale a un agente de codificación local (un asistente de IA que puede inspeccionar y ejecutar comandos en su repositorio local) que inspeccione su dd-tracepaquete instalado y ejecute su manual de validación de Test Optimization. Este método verifica la compatibilidad de la biblioteca local y la configuración de CI. También verifica Early Flake Detection, Auto Test Retries y Test Management sin cambiar la configuración de Datadog ni enviar resultados de validación a Datadog.

El manual se encuentra en ci/runbook.md en relación con la raíz del paquete dd-trace instalado.

Pase este prompt a su agente de codificación local:

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

Este método de agente de codificación es una verificación local que no ejecuta todo el flujo de trabajo de Datadog. Para validar los flujos de trabajo completos de Prevención, Mitigación y Remediación, o para validar un lenguaje distinto a JavaScript o TypeScript, use la Opción 2, a continuación.

Opción 2: Validar el flujo de trabajo completo

Este flujo de trabajo de validación comprueba el flujo de trabajo completo de Test Optimization en Datadog. Realice estas validaciones (Prevención, Mitigación y Remediación) en orden, ya que utilizan la misma rama y la prueba.

Paso 1: Configurar la validación

Esta guía lo lleva a través de la realización de cambios locales y su confirmación para que la CI los ejecute. Utiliza un servicio de pruebas y una rama dedicados para minimizar el impacto del flujo de trabajo de validación en otros desarrolladores del repositorio.

Configure su trabajo de prueba de CI para establecer DD_SERVICE antes de que ejecute el comando de prueba:
```
export DD_SERVICE=validate-test-optimization
```

Cree la rama de validación:

git checkout -b validate-test-optimization

Confirme el cambio de configuración de CI que establece DD_SERVICE, luego envíe la rama de validación para activar una ejecución de prueba:
```
git add -A
git commit -m "Configure Test Optimization validation service"
git push -u origin validate-test-optimization
```
Datadog detecta el validate-test-optimizationservicio cuando las pruebas se reportan bajo ese nombre.
Después de que finalice la CI, vaya a la configuración de repositorios de CI/CD y seleccione el repositorio que está validando.
En la esquina superior derecha del panel deslizante, haga clic en Test Service.
En Test service overrides, seleccione el validate-test-optimization servicio.
Configure las siguientes anulaciones de servicio de pruebas:
- Habilite Early Flake Detection.
- Habilite Auto Test Retries.
- Deshabilite Test Impact Analysis (para que no omita la prueba de validación).
Regrese a la configuración del repositorio. Flaky Test Policies se aplican a cada servicio de pruebas en el repositorio, no a un servicio de pruebas individual. Para limitar el impacto de la política de validación, configúrela solo para la rama validate-test-optimization. En Flaky Test Policies, en el mosaico Quarantine, haga clic en Configure.
Habilite la segunda regla automática: Si una prueba inestable activa falla en la rama validate-test-optimization, muévala a Cuarentena.
Haga clic en Save.
Cree un New Flaky Test PR Gate y asígnele el contexto del repositorio que está validando.

Contexto de la nueva puerta de PR para pruebas inestables

Paso 2: Prevención

Early Flake Detection detecta nuevas pruebas inestables. New Flaky Test PR Gates evitan que las nuevas pruebas inestables lleguen a su rama predeterminada.

Agregue una prueba que falle en el primer intento y pase en los reintentos (opcionalmente usando el código proporcionado a continuación). El nombre de la prueba debe contener tanto flaky como validation para que pueda identificarla en 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")
        }
    }
}

Confirme y envíe (push) la prueba, luego abra una solicitud de extracción (pull request) desde la rama de validación:
```
git add -A
git commit -m "Validate Test Optimization prevention"
git push origin validate-test-optimization
```
Espere a que se ejecute la CI. La detección temprana de inestabilidad (Early Flake Detection) reintenta la nueva prueba, y la puerta de PR de nueva prueba inestable (New Flaky Test PR Gate) evalúa el resultado. En las verificaciones de GitHub para su solicitud de extracción, confirme que la puerta de PR de nueva prueba inestable (New Flaky Test PR Gate) falle:
Haga clic en la verificación de GitHub fallida y confirme que la prueba esté incluida en la lista de nuevas pruebas inestables:
En Test Runs, confirme que la detección temprana de inestabilidad (Early Flake Detection) reintentó la prueba y la detectó como una nueva prueba inestable usando esta consulta, que utiliza los siguientes filtros:
- @test.name:*flaky*validation*
- @git.branch:validate-test-optimization
- @test.retry_reason:early_flake_detection
- @test.test_management.is_new_flaky:true

Paso 3: Mitigación

La mitigación se logra a través de Auto Test Retries, Flaky Test Management y Flaky Test Policies. Estas funciones reintentan las pruebas inestables y ponen en cuarentena las fallas inestables conocidas para que no bloqueen la CI.

En la misma prueba que agregó para Prevención, cambie el nombre del archivo de marcador de dd-validation-flaky a dd-validation-flaky-mitigation. No cambie el nombre de la función de prueba ni del caso de prueba. El nuevo marcador provoca otra falla intencional en el primer intento. Mantener el nombre de la prueba sin cambios permite que Datadog asocie la ejecución con la prueba inestable detectada durante la Prevención. No se requiere configuración adicional de Datadog; Auto Test Retries y Flaky Test Management manejan la prueba durante esta ejecución. Actualice la prueba para su idioma:

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")
        }
    }
}

Confirme y envíe (push) el cambio en la misma rama:

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

Espere a que se ejecute la CI y, a continuación, confirme los siguientes resultados:
- En Test Runs, Auto Test Retries vuelve a ejecutar la prueba después de su primer intento fallido, y la prueba pasa en el reintento. Utilice esta consulta, con los siguientes filtros:
  - @test.name:*flaky*validation*
  - @git.branch:validate-test-optimization
  - @test.retry_reason:auto_test_retry
- En Flaky Test Management, la prueba aparece como QUARANTINED. Sus fallos ya no bloquean el trabajo de prueba. Utilice esta consulta, con los siguientes filtros:
  - @test.name:*flaky*validation*
  - first_flaked_branch:validate-test-optimization
  - flaky_test_state:quarantined

Paso 4: Remediación

Test Optimization ayuda a corregir pruebas inestables mediante Attempt to Fix y correcciones de pruebas inestables con Bits AI. Esta sección valida el flujo de trabajo Attempt to Fix corrigiendo la misma prueba utilizada para Prevención y Mitigación.

En Flaky Test Management, abra la prueba de validación en cuarentena.
Haga clic en Actions, seleccione Link commit to fix y copie la clave generada (comienza con DD_).

Reemplace la prueba inestable con la versión aprobada para su idioma:

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)
}

Confirme la corrección con la clave generada en el cuerpo de la confirmación. Reemplace <YOUR_DD_KEY> con la clave que copió:
```
git add -A
git commit -m "Fix flaky validation test" -m "<YOUR_DD_KEY>"
git push origin validate-test-optimization
```
Espere a que finalice la CI y, a continuación, confirme los siguientes resultados:
- En Test Runs, Attempt to Fix volvió a intentar el candidato a corrección y todos los intentos fueron exitosos. Utilice esta consulta, que tiene los siguientes filtros:
  - @test.name:*flaky*validation*
  - @git.branch:validate-test-optimization
  - @test.test_management.is_attempt_to_fix:true
- En Flaky Test Management, la prueba está marcada como Fix in progress. Utilice esta consulta, que tiene los siguientes filtros:
  - @test.name:*flaky*validation*
  - first_flaked_branch:validate-test-optimization
  - fix_in_progress:true

Paso 5: Limpieza posterior a la validación

Cierre la solicitud de extracción sin fusionar.
Elimine la rama validate-test-optimization. La regla automática de cuarentena específica de la rama ya no se aplica después de que se elimina la rama, y el servicio de validación dedicado ya no recibe ejecuciones de prueba.
Notifique al equipo propietario del repositorio que el New Flaky Test PR Gate permanece activo para todo el repositorio. La puerta no es bloqueante de forma predeterminada.
Opcionalmente, habilite las funciones de Test Optimization configuradas para el servicio validate-test-optimization a nivel de repositorio.

Lecturas adicionales

Documentación, enlaces y artículos útiles adicionales:

Configure un [New Flaky Test PR Gate]DOCUMENTACIÓN

Obtenga información sobre Early Flake DetectionDOCUMENTACIÓN

Obtenga información sobre Auto Test RetriesDOCUMENTACIÓN

Obtenga información sobre Flaky Test ManagementDOCUMENTACIÓN