CI Visibility no está disponible en el sitio seleccionado () en este momento.

Compatibilidad

Marcos de test compatibles:

Marco de testVersiónNotas
Jest>= 24.8.0Solo jsdom (en el paquete jest-environment-jsdom) y node (en el paquete jest-environment-node) son compatibles como entornos de test. Los entornos personalizados como @jest-runner/electron/environment en jest-electron-runner no son compatibles.

Solo jest-circus es compatible como testRunner.

test.concurrent no es compatible.
Mocha>= 5.2.0Mocha >= 9.0.0 tiene compatibilidad parcial.
Cucumber>= 7.0.0
Cypress>= 6.7.0
Playwright>= 1.18.0
Vitest>= 1.16.0Compatible desde dd-trace>=4.42.0 y dd-trace>=5.18.0. Solo es compatible desde Node.js>=18.19 o Node.js>=20.6

La instrumentación funciona en el tiempo de ejecución, por lo que los transcompiladores como TypeScript, Webpack o Babel son compatibles de forma predefinida.

Configuración del método de informes

Para informar resultados de tests a Datadog, debes configurar la biblioteca de Datadog JavaScript:

Puedes usar la acción Datadog Test Visibility Github dedicada para activar la visibilidad de test. Si lo haces, el resto de los pasos de configuración a continuación pueden omitirse.

Puedes usar la configuración basada en la interfaz de usuario para activar la Visibilidad de test para tus trabajos y pipelines. Si lo haces, el resto de los pasos de configuración a continuación pueden omitirse.

El modo sin Agent está disponible en las versiones de la biblioteca de Datadog JavaScript >= 2.5.0
If you are using a cloud CI provider without access to the underlying worker nodes, such as GitHub Actions or CircleCI, configure the library to use the Agentless mode. For this, set the following environment variables:
DD_CIVISIBILITY_AGENTLESS_ENABLED=true (Required)
Enables or disables Agentless mode.
Default: false
DD_API_KEY (Required)
The Datadog API key used to upload the test results.
Default: (empty)

Additionally, configure the Datadog site to which you want to send data.

DD_SITE (Required)
The Datadog site to upload results to.
Default: datadoghq.com

If you are running tests on an on-premises CI provider, such as Jenkins or self-managed GitLab CI, install the Datadog Agent on each worker node by following the Agent installation instructions. This is the recommended option as it allows you to automatically link test results to logs and underlying host metrics.

If you are using a Kubernetes executor, Datadog recommends using the Datadog Operator. The operator includes Datadog Admission Controller which can automatically inject the tracer library into the build pods. Note: If you use the Datadog Operator, there is no need to download and inject the tracer library since the Admission Controller can do this for you, so you can skip the corresponding step below. However, you still need to make sure that your pods set the environment variables or command-line parameters necessary to enable Test Visibility.

If you are not using Kubernetes or can’t use the Datadog Admission Controller and the CI provider is using a container-based executor, set the DD_TRACE_AGENT_URL environment variable (which defaults to http://localhost:8126) in the build container running the tracer to an endpoint that is accessible from within that container. Note: Using localhost inside the build references the container itself and not the underlying worker node or any container where the Agent might be running in.

DD_TRACE_AGENT_URL includes the protocol and port (for example, http://localhost:8126) and takes precedence over DD_AGENT_HOST and DD_TRACE_AGENT_PORT, and is the recommended configuration parameter to configure the Datadog Agent’s URL for CI Visibility.

If you still have issues connecting to the Datadog Agent, use the Agentless Mode. Note: When using this method, tests are not correlated with logs and infrastructure metrics.

Instalación del rastreador de JavaScript

Para instalar el rastreador de JavaScript, ejecuta:

yarn add --dev dd-trace

Para obtener más información, consulta la documentación del rastreador de JavaScript.

Instrumenta tus tests

Establece la variable de entorno NODE_OPTIONS en -r dd-trace/ci/init. Run your tests as you normally would, specifying the environment where the tests are run in the DD_ENV environment variable. For example, set DD_ENV to local when running tests on a developer workstation, or ci cuando se ejecuta en un proveedor de CI:

NODE_OPTIONS="-r dd-trace/ci/init" DD_ENV=ci DD_SERVICE=my-javascript-app yarn test

Nota: Si estableces un valor para NODE_OPTIONS, asegúrate que no sobrescriba la cláusula -r dd-trace/ci/init. This can be done using the ${NODE_OPTIONS:-}:

package.json

{
  "scripts": {
    "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" jest"
  }
}

Añade etiquetas personalizadas a tests

Puedes añadir etiquetas personalizadas a tus tests mediante el tramo activo en ese momento:

  it('sum function can sum', () => {
    const testSpan = require('dd-trace').scope().active()
    testSpan.setTag('team_owner', 'my_team')
    // test continúa normalmente
    // ...
  })

Para crear filtros o campos group by para estas etiquetas, primero debes crear facetas. Para obtener más información sobre añadir etiquetas, consulta la sección Añadir etiquetas de la documentación de la instrumentación personalizada de Node.js.

Añadir medidas personalizadas a tests

Como con las etiquetas, puedes añadir medidas personalizadas a tus tests mediante el tramo activo en ese momento:

  it('sum function can sum', () => {
    const testSpan = require('dd-trace').scope().active()
    testSpan.setTag('memory_allocations', 16)
    // test continúa normalmente
    // ...
  })

Para más información sobre las medidas personalizadas, consulta la guía Añadir medidas personalizadas.

Establece la variable de entorno NODE_OPTIONS en -r dd-trace/ci/init. Run your tests as you normally would, specifying the environment where the tests are run in the DD_ENV environment variable. For example, set DD_ENV to local when running tests on a developer workstation, or ci cuando lo ejecutas en un proveedor de CI:

NODE_OPTIONS="-r dd-trace/ci/init" DD_ENV=ci DD_SERVICE=my-javascript-app yarn test

Nota: Si estableces un valor de NODE_OPTIONS, asegúrate que no sobrescriba la cláusula -r dd-trace/ci/init. This can be done using the ${NODE_OPTIONS:-}:

package.json

{
  "scripts": {
    "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" jest"
  }
}

Añadir etiquetas personalizadas a tests

Puedes añadir etiquetas personalizadas a tus tests mediante la API de anotaciones personalizadas de Playwright:

test('user profile', async ({ page }) => {
  test.info().annotations.push({
    type: 'DD_TAGS[test.memory.usage]', // DD_TAGS es obligatorio y distingue entre mayúscula y minúscula
    description: 'low',
  });
  test.info().annotations.push({
    type: 'DD_TAGS[test.task.id]',
    description: '41123',
  });
  // ...
});

test('landing page', async ({ page }) => {
  test.info().annotations.push({
    type: 'DD_TAGS[test.cpu.usage]',
    description: 'high',
  });
  // ...
});

El formato de las anotaciones es el siguiente, donde $TAG_NAME y $TAG_VALUE son cadenas que representan el nombre de etiqueta y el valor, respectivamente:

{
  "type": "DD_TAGS[$TAG_NAME]",
  "description": "$TAG_VALUE"
}

Añadir medidas personalizadas a tests

Las medidas personalizadas también usan anotaciones personalizadas:

test('user profile', async ({ page }) => {
  test.info().annotations.push({
    type: 'DD_TAGS[test.memory.allocations]', // DD_TAGS es obligatorio y distingue entre mayúscula y minúscula
    description: 16, // este es un número
  });
});

El formato de las anotaciones es el siguiente, donde $TAG_NAME es una cadena que representa el nombre de etiqueta y $TAG_VALUE es un número que representa el valor de etiqueta:

{
  "type": "DD_TAGS[$TAG_NAME]",
  "description": $TAG_VALUE
}

*Nota: Los valores description en anotaciones se escriben como cadenas. Los números también funcionan, pero debes desactivar el error de escritura con // @ts-expect-error.

Importante: El prefijo DD_TAGS es obligatorio y distingue entre mayúscula y minúscula.

Establece la variable de entorno NODE_OPTIONS en -r dd-trace/ci/init. Run your tests as you normally would, specifying the environment where the tests are run in the DD_ENV environment variable. For example, set DD_ENV to local when running tests on a developer workstation, or ci cuando lo ejecute en un proveedor de CI:

NODE_OPTIONS="-r dd-trace/ci/init" DD_ENV=ci DD_SERVICE=my-javascript-app yarn test

Nota: Si estableces un valor para NODE_OPTIONS, asegúrate de que no sobrescriba la cláusula -r dd-trace/ci/init. This can be done using the ${NODE_OPTIONS:-}:

package.json

{
  "scripts": {
    "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" jest"
  }
}

Añadir etiquetas personalizadas a los tests

Puedes añadir etiquetas personalizadas a tus tests con el tramo activo en ese momento:

  When('the function is called', function () {
    const stepSpan = require('dd-trace').scope().active()
    testSpan.setTag('team_owner', 'my_team')
    // test continúa normalment
    // ...
  })

Para crear filtros o campos group by para estas etiquetas, primero debes crear facetas. Para obtener más información sobre la adición de etiquetas, consulta la sección Adición de etiquetas de la documentación de instrumentación personalizada de Node.js.

Añadir medidas personalizadas a los tests

También puedes añadir medidas personalizadas a tu test con el tramo que esté activo en ese momento:

  When('the function is called', function () {
    const stepSpan = require('dd-trace').scope().active()
    testSpan.setTag('memory_allocations', 16)
    // test continúa normalmente
    // ...
  })

Para obtener más información sobre las medidas personalizadas, consulta la guía para Añadir medidas personalizadas.

Cypress versión 10 o posterior

Utiliza la documentación de la API de Cypress para aprender a utilizar los complementos para cypress>=10.

En tu archivo cypress.config.js, establece lo siguiente:

cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    setupNodeEvents: require('dd-trace/ci/cypress/plugin'),
    supportFile: 'cypress/support/e2e.js'
  }
})

Añade la siguiente línea al nivel superior de tu supportFile:

cypress/support/e2e.js

// Tu código puede ir antes de esta línea
// require('./commands')
require('dd-trace/ci/cypress/support')
// También compatible:
// import 'dd-trace/ci/cypress/support'
// Tu código también puede ir después de esta línea
// Cypress.Commands.add('login', (email, pw) => {})

Si utilizas otros complementos de Cypress, tu archivo cypress.config.js debe contener lo siguiente:

cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      // tu código previo va antes de esta línea
      require('dd-trace/ci/cypress/plugin')(on, config)
    }
  }
})

Evento after:run de Cypress

Datadog requiere el evento after:run de Cypress para funcionar, y Cypress no permite múltiples manejadores para ese evento. Si ya has definido manejadores para after:run, añade el manejador de Datadog manualmente al importar 'dd-trace/ci/cypress/after-run':

cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      require('dd-trace/ci/cypress/plugin')(on, config)
      // otros complementos
      on('after:run', (details) => {
        // otros manejadores 'after:run'
        // importante que se devuelva esta función
        return require('dd-trace/ci/cypress/after-run')(details)
      })
    }
  }
})

Evento after:spec de Cypress

Datadog requiere el evento after:spec de Cypress para funcionar, y Cypress no permite múltiples manejadores para ese evento. Si ya has definido manejadores para after:spec, añade el manejador de Datadog manualmente al importar 'dd-trace/ci/cypress/after-spec':

cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      require('dd-trace/ci/cypress/plugin')(on, config)
      // otros complementos
      on('after:spec', (...args) => {
        // otros manejadores 'after:spec'
        // Importante que se devuelva esta función
        // Importante que todos los argumentos se pasen
        return require('dd-trace/ci/cypress/after-spec')(...args)
      })
    }
  }
})

Cypress antes de la versión 10

Estas son las instrucciones si estás utilizando una versión anterior a cypress@10. Consulta la documentación de Cypress para obtener más información sobre la migración a una versión más reciente.

  1. Establece pluginsFile en "dd-trace/ci/cypress/plugin", por ejemplo, a través de cypress.json:

cypress.json

{
  "pluginsFile": "dd-trace/ci/cypress/plugin"
}

Si ya has definido un pluginsFile, inicializa la instrumentación con:

cypress/plugins/index.js

module.exports = (on, config) => {
  // tu código previo va antes de esta línea
  require('dd-trace/ci/cypress/plugin')(on, config)
}
  1. Añade la siguiente línea al nivel superior de tu supportFile:

cypress/support/index.js

// Tu código puede estar antes de esta línea
// require('./commands')
require('dd-trace/ci/cypress/support')
// Tu código también puede estar después de esta línea
// Cypress.Commands.add('login', (email, pw) => {})

Evento after:run de Cypress

Datadog requiere el evento after:run de Cypress para funcionar, y Cypress no permite múltiples manejadores para ese evento. Si ya has definido manejadores para after:run, añade el manejador de Datadog manualmente al importar 'dd-trace/ci/cypress/after-run':

cypress/plugins/index.js

module.exports = (on, config) => {
  // tu código anterior va antes de esta línea
  require('dd-trace/ci/cypress/plugin')(on, config)
  on('after:run', (details) => {
    // otros manejadores 'after:run'
    // importante que se devuelva esta llamada a la función
    return require('dd-trace/ci/cypress/after-run')(details)
  })
}

Evento after:spec de Cypress

Datadog requiere el evento after:spec de Cypress para funcionar, y Cypress no permite múltiples manejadores para ese evento. Si ya has definido manejadores para after:spec, añade el manejador de Datadog manualmente al importar 'dd-trace/ci/cypress/after-spec':

cypress/plugins/index.js

module.exports = (on, config) => {
  // tu código anterior va antes de esta línea
  require('dd-trace/ci/cypress/plugin')(on, config)
  on('after:spec', (...args) => {
    // otros manejadores 'after:spec'
    // Importante que se devuelva esta llamada a la función
    // Importante que todos los argumentos se pasen
    return require('dd-trace/ci/cypress/after-run')(...args)
  })
}

Ejecuta tus tests como lo haces normalmente, especificando el entorno donde se están ejecutando (por ejemplo, local cuando se ejecutan los tests en una estación de trabajo de desarrollador, o ci cuando se ejecutan en un proveedor de CI) en la variable de entorno DD_ENV. Por ejemplo:

DD_ENV=ci DD_SERVICE=my-ui-app npm test

Añadir etiquetas personalizadas a los tests

Para añadir información adicional a tus tests, como el propietario del equipo, utiliza cy.task('dd:addTags', { yourTags: 'here' }) en tu testo hooks.

Por ejemplo:

beforeEach(() => {
  cy.task('dd:addTags', {
    'before.each': 'certain.information'
  })
})
it('renders a hello world', () => {
  cy.task('dd:addTags', {
    'team.owner': 'ui'
  })
  cy.get('.hello-world')
    .should('have.text', 'Hello World')
})

Para crear filtros o campos group by para estas etiquetas, primero debes crear facetas. Para más información sobre cómo añadir etiquetas, consulta la sección Añadir etiquetas de la documentación de instrumentación personalizada de Node.js.

Añadir medidas personalizadas a los tests

Para añadir información adicional a tus tests, como asignaciones de memoria, utiliza cy.task('dd:addTags', { yourNumericalTags: 1 }) en tu test o hooks.

Por ejemplo:

it('renders a hello world', () => {
  cy.task('dd:addTags', {
    'memory_allocations': 16
  })
  cy.get('.hello-world')
    .should('have.text', 'Hello World')
})

Para obtener más información sobre las medidas personalizadas, consulta la guía para Añadir medidas personalizadas.

Cypress: integración de RUM

Si la aplicación de navegador que se está probando se instrumenta con la Monitorización de navegador, los resultados de los tests de Cypress y sus sesiones de navegador RUM generadas y las repeticiones de sesión se vinculan automáticamente. Para obtener más información, consulta la guía para Instrumentar tus tests de navegador con RUM.

Nota: Vitest es ESM primero, por lo que su configuración es diferente de otros marcos de test.

vitest y dd-trace requieren Node.js>=18.19 o Node.js>=20.6 para funcionar.

Establece la variable de entorno NODE_OPTIONS en --import dd-trace/register.js -r dd-trace/ci/init. Run your tests as you normally would, specifying the environment where the tests are run in the DD_ENV environment variable. For example, set DD_ENV to local when running tests on a developer workstation, or ci cuando se ejecute en un proveedor de CI:

NODE_OPTIONS="--import dd-trace/register.js -r dd-trace/ci/init" DD_ENV=ci DD_SERVICE=my-javascript-app yarn test

Nota: Si estableces un valor para NODE_OPTIONS, asegúrate de que no sobrescriba la cláusula --import dd-trace/register.js -r dd-trace/ci/init. This can be done using the ${NODE_OPTIONS:-}:

package.json

{
  "scripts": {
    "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" vitest run"
  }
}

Añadir etiquetas o medidas personalizadas a los tests

No compatible.

Cómo solucionar los errores “No se encuentra el módulo ‘dd-trace/ci/init’”.

Al utilizar dd-trace, es posible que aparezca el siguiente mensaje de error:

 Error: Cannot find module 'dd-trace/ci/init'

Esto puede deberse a un uso incorrecto de NODE_OPTIONS.

Por ejemplo, si tu acción de GitHub tiene este aspecto:

jobs:
  my-job:
    name: Run tests
    runs-on: ubuntu-latest
    env:
      NODE_OPTIONS: -r dd-trace/ci/init
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
      - name: Install node
        uses: actions/setup-node@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test

Nota: Esto no funciona porque NODE_OPTIONS es interpretado por cada proceso de nodo, incluido npm install. Si intentas importar dd-trace/ci/init antes de que esté instalado, este paso falla.

Tu acción de GitHub debería tener este aspecto:

jobs:
  my-job:
    name: Run tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
      - name: Install node
        uses: actions/setup-node@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
        env:
          NODE_OPTIONS: -r dd-trace/ci/init

Sigue estas prácticas recomendadas:

  • Asegúrate de que la variable de entorno NODE_OPTIONS solo está configurada en el proceso que ejecuta los tests.
  • En concreto, evita definir NODE_OPTIONS en la configuración de variables globales de entorno en la definición de tu proceso o trabajo.

Con Yarn 2 o posterior

Si utilizas yarn>=2 y un archivo .pnp.cjs, también puedes obtener el mismo error:

 Error: Cannot find module 'dd-trace/ci/init'

Puedes solucionarlo configurando NODE_OPTIONS de la siguiente manera:

NODE_OPTIONS="-r $(pwd)/.pnp.cjs -r dd-trace/ci/init" yarn test

Informar sobre la cobertura del código

Cuando los tests se instrumentan con Istambul, el rastreador de Datadog (v3.20.0 o posterior) informa de ello en la etiqueta test.code_coverage.lines_pct para tus sesiones de test.

Puedes ver la evolución de la cobertura de los tests en la pestaña Coverage (Cobertura) de una sesión de tests.

Para más información, consulta Cobertura del código.

Ajustes de configuración

A continuación, se muestra una lista de los ajustes más importantes de configuración que se pueden utilizar con el rastreador.

service
nombre del servicio o biblioteca en proceso de test.
**Variable de entorno **: DD_SERVICE
Por defecto: (nombre del marco de test)
Ejemplo: my-ui
env
nombre del entorno donde se están ejecutando los tests.
**Variable de entorno **: DD_ENV
Por defecto: none
Ejemplos: local, ci
url
URL del Datadog Agent para la recopilación de trazas con el formato http://hostname:port.
Variable de entorno: DD_TRACE_AGENT_URL
Por defecto: http://localhost:8126

Para más información sobre etiquetas service y env reservadas, consulta Etiquetado de servicios unificado. También se pueden utilizar todas las demás opciones de configuración del rastreador de Datadog.

Recopilación de metadatos Git

Datadog uses Git information for visualizing your test results and grouping them by repository, branch, and commit. Git metadata is automatically collected by the test instrumentation from CI provider environment variables and the local .git folder in the project path, if available.

If you are running tests in non-supported CI providers or with no .git folder, you can set the Git information manually using environment variables. These environment variables take precedence over any auto-detected information. Set the following environment variables to provide Git information:

DD_GIT_REPOSITORY_URL
URL of the repository where the code is stored. Both HTTP and SSH URLs are supported.
Example: git@github.com:MyCompany/MyApp.git, https://github.com/MyCompany/MyApp.git
DD_GIT_BRANCH
Git branch being tested. Leave empty if providing tag information instead.
Example: develop
DD_GIT_TAG
Git tag being tested (if applicable). Leave empty if providing branch information instead.
Example: 1.0.1
DD_GIT_COMMIT_SHA
Full commit hash.
Example: a18ebf361cc831f5535e58ec4fae04ffd98d8152
DD_GIT_COMMIT_MESSAGE
Commit message.
Example: Set release number
DD_GIT_COMMIT_AUTHOR_NAME
Commit author name.
Example: John Smith
DD_GIT_COMMIT_AUTHOR_EMAIL
Commit author email.
Example: john@example.com
DD_GIT_COMMIT_AUTHOR_DATE
Commit author date in ISO 8601 format.
Example: 2021-03-12T16:00:28Z
DD_GIT_COMMIT_COMMITTER_NAME
Commit committer name.
Example: Jane Smith
DD_GIT_COMMIT_COMMITTER_EMAIL
Commit committer email.
Example: jane@example.com
DD_GIT_COMMIT_COMMITTER_DATE
Commit committer date in ISO 8601 format.
Example: 2021-03-12T16:00:28Z

API para tests manuales

Nota: Para utilizar la API de tests manuales, debes pasar DD_CIVISIBILITY_MANUAL_API_ENABLED=1 como variable de entorno.
Nota: La API de tests manuales está en fase beta, por lo que podría sufrir modificaciones. Está disponible a partir de las versiones 4.4.0, 3.25.0 y 2.38.0 de dd-trace.

Si utilizas Jest, Mocha, Cypress, Playwright, Cucumber o Vitest, no utilices la API de tests manuales, ya que CI Visibility los instrumenta automáticamente y envía los resultados a Datadog. La API de tests manuales es incompatible con los marcos de test que ya son compatibles.

Utiliza la API de tests manuales solo si utilizas un marco de test no compatible o tienes un mecanismo de test diferente.

La API de tests manuales aprovecha el módulo node:diagnostics_channel de Node.js y se basa en canales en los que se puede publicar:

const { channel } = require('node:diagnostics_channel')

const { describe, test, beforeEach, afterEach, assert } = require('my-custom-test-framework')

const testStartCh = channel('dd-trace:ci:manual:test:start')
const testFinishCh = channel('dd-trace:ci:manual:test:finish')
const testSuite = __filename

describe('can run tests', () => {
  beforeEach((testName) => {
    testStartCh.publish({ testName, testSuite })
  })
  afterEach((status, error) => {
    testFinishCh.publish({ status, error })
  })
  test('first test will pass', () => {
    assert.equal(1, 1)
  })
})

Canal de inicio del test

Toma este canal por su ID dd-trace:ci:manual:test:start para publicar que se está iniciando un test. Un buen lugar para hacer esto es un hook beforeEach o similar.

const { channel } = require('node:diagnostics_channel')
const testStartCh = channel('dd-trace:ci:manual:test:start')

// ... el código para tu marco de test va aquí
  beforeEach(() => {
    const testDefinition = {
      testName: 'a-string-that-identifies-this-test',
      testSuite: 'what-suite-this-test-is-from.js'
    }
    testStartCh.publish(testDefinition)
  })
// el código para tu marco de test continúa aquí ...

La carga útil que se va a publicar tiene los atributos testName y testSuite, ambos cadenas, que identifican el test que está a punto de comenzar.

Canal de finalización del test

Toma este canal por su ID dd-trace:ci:manual:test:finish para publicar que se está finalizando un test. Un buen lugar para hacer esto es un hook afterEach o similar.

const { channel } = require('node:diagnostics_channel')
const testFinishCh = channel('dd-trace:ci:manual:test:finish')

// ... el código para tu marco de test va aquí
  afterEach(() => {
    const testStatusPayload = {
      status: 'fail',
      error: new Error('assertion error')
    }
    testStartCh.publish(testStatusPayload)
  })
// el código para tu marco de test continúa aquí ...

La carga útil que se va a publicar tiene los atributos status y error:

  • status es una cadena que toma uno de tres valores:

    • 'pass' cuando se supera un test.
    • 'fail' cuando falla un test.
    • 'skip' cuando se ha omitido un test.
  • error es un objeto Error que contiene la razón por la que ha fallado un test.

Añadir etiquetas de canal

Toma este canal por su ID dd-trace:ci:manual:test:addTags para publicar que un test necesita etiquetas personalizadas. Esto puede hacerse dentro de la función de test:

const { channel } = require('node:diagnostics_channel')
const testAddTagsCh = channel('dd-trace:ci:manual:test:addTags')

// ... el código para tu marco de test va aquí
  test('can sum', () => {
    testAddTagsCh.publish({ 'test.owner': 'my-team', 'number.assertions': 3 })
    const result = sum(2, 1)
    assert.equal(result, 3)
  })
// el código para tu marco de test continúa aquí ...

La carga útil que se publica es un diccionario <string, string|number> de etiquetas o medidas que se añaden al test.

Ejecutar los tests

Cuando los canales de inicio y fin del test estén en tu código, ejecuta tu marco de test como lo haces normalmente, incluyendo las siguientes variables de entorno:

NODE_OPTIONS="-r dd-trace/ci/init" DD_CIVISIBILITY_MANUAL_API_ENABLED=1 DD_ENV=ci DD_SERVICE=my-custom-framework-tests yarn run-my-test-framework

Limitaciones conocidas

Módulos ES

Mocha >=9.0.0 utiliza un enfoque primero ESM para cargar archivos de test. Esto significa que si se utilizan módulos ES (por ejemplo, al definir archivos de test con la extensión .mjs), la instrumentación está limitada. Los tests se detectan, pero no hay visibilidad de tu test. Para más información sobre los módulos ES, consulta la documentación de Node.js.

Tests de navegador

Los tests de navegador ejecutados con mocha, jest, cucumber, cypress, playwright y vitest son instrumentados por dd-trace-js, pero la visibilidad de la sesión del navegador en sí no se proporciona por defecto (por ejemplo, llamadas de red, acciones del usuario, cargas de páginas, etc.).

Si quieres visibilidad del proceso de navegador, considera el uso de RUM y Session Replay. Cuando se utiliza Cypress, los resultados de los tests y sus sesiones de navegador RUM generadas y las repeticiones de sesión se vinculan automáticamente. Para más información, consulta la guía para Instrumentar tus tests de navegador con RUM.

Modo interactivo de Cypress

El modo interactivo de Cypress (al que puedes entrar ejecutando cypress open) no es compatible con CI Visibility porque algunos eventos de Cypress, como before:run, no se activan. Si quieres probarlo de todas formas, pasa experimentalInteractiveRunEvents: true al archivo de configuración de Cypress.

test.concurrent de Jest

No se admite test.concurrent de Jest.

--forceExit de Jest

La opción –forceExit de Jest puede causar pérdida de datos. Datadog intenta enviar datos inmediatamente después de que tus tests terminen, pero cerrar el proceso abruptamente puede causar que algunas solicitudes fallen. Usa --forceExit con precaución.

--exit de Mocha

La opción –exit de Mocha puede causar pérdida de datos. Datadog intenta enviar datos inmediatamente después de que tus tests terminen, pero cerrar el proceso abruptamente puede causar que algunas solicitudes fallen. Usa --exit con precaución.

Prácticas recomendadas

Sigue estas prácticas para aprovechar al máximo el marco de test y CI Visibility.

Tests parametrizados

Siempre que sea posible, aprovecha las herramientas que ofrecen los marcos de test para realizar tests parametrizados. Por ejemplo, para jest:

Evita esto:

[[1,2,3], [3,4,7]].forEach((a,b,expected) => {
  test('sums correctly', () => {
    expect(a+b).toEqual(expected)
  })
})

Y usa test.each en su lugar:

test.each([[1,2,3], [3,4,7]])('sums correctly %i and %i', (a,b,expected) => {
  expect(a+b).toEqual(expected)
})

Para mocha, utiliza mocha-each:

const forEach = require('mocha-each');
forEach([
  [1,2,3],
  [3,4,7]
])
.it('adds %i and %i then returns %i', (a,b,expected) => {
  expect(a+b).to.equal(expected)
});

Cuando se utiliza este enfoque, tanto el marco de test como CI Visibility pueden distinguir tus tests.

Referencias adicionales

PREVIEWING: rtrieu/product-analytics-ui-changes