Como gerar relatórios JUNIT no Playwright

Gerar relatórios em formato JUnit é uma prática comum em ambientes de desenvolvimento de software, especialmente em cenários de integração contínua (CI) e entrega contínua (CD), como Jenkins, Azure DevOps, GitLab CI/CD, e muitas outras. Isso significa que, ao gerar relatórios nesse formato, você pode integrar facilmente os resultados dos testes com esses sistemas, permitindo o monitoramento automático e a análise dos resultados dos testes.

Tais ferramentas utilizam o formato JUnit para apresentar visualmente os resultados dos testes, permitindo que os desenvolvedores vejam rapidamente quais testes passaram, falharam, ou foram ignorados. Isso melhora a eficiência ao identificar problemas no código e facilita o rastreamento de regressões ou novos bugs. Tais resultados podem ser usados para configurar a pipeline para falhar automaticamente se houver testes que não passaram, evitando que código problemático seja promovido para ambientes de produção.

Portanto, é essencial que seus testes E2E gerem um relatório no formato JUnit, permitindo que ele seja facilmente acessado na ferramenta de CI/CD escolhida pela sua equipe. No Playwright, basta realizar uma configuração simples no arquivo playwright.config.ts para garantir que o relatório em formato JUnit seja gerado automaticamente ao final da execução dos testes, adicionando o seguinte trecho dentro do export default defineConfig:

reporter: [
  ['list'], // Repórter padrão para saída em console
  ['junit', { outputFile: 'test-results/junit-results.xml' }] 
],

Tendo a configuração padrão do Playwright, o seu arquivo de configuração deve ficar da seguinte forma:

import { defineConfig, devices } from '@playwright/test';

/**
 * Read environment variables from file.
 * https://github.com/motdotla/dotenv
 */
// import dotenv from 'dotenv';
// dotenv.config({ path: path.resolve(__dirname, '.env') });

/**
 * See https://playwright.dev/docs/test-configuration.
 */
export default defineConfig({
  testDir: './tests',
  /* Run tests in files in parallel */
  fullyParallel: true,
  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,
  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,
  /* Opt out of parallel tests on CI. */
  workers: process.env.CI ? 1 : undefined,
  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
  reporter: [
    ['list'], // Repórter padrão para saída em console
    ['junit', { outputFile: 'test-results/junit-results.xml' }] // Configuração para JUnit
  ],
  /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    // baseURL: 'http://127.0.0.1:3000',

    /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
    trace: 'on-first-retry',
  },

  /* Configure projects for major browsers */
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },

    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },

    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },

    /* Test against mobile viewports. */
    // {
    //   name: 'Mobile Chrome',
    //   use: { ...devices['Pixel 5'] },
    // },
    // {
    //   name: 'Mobile Safari',
    //   use: { ...devices['iPhone 12'] },
    // },

    /* Test against branded browsers. */
    // {
    //   name: 'Microsoft Edge',
    //   use: { ...devices['Desktop Edge'], channel: 'msedge' },
    // },
    // {
    //   name: 'Google Chrome',
    //   use: { ...devices['Desktop Chrome'], channel: 'chrome' },
    // },
  ],

  /* Run your local dev server before starting the tests */
  // webServer: {
  //   command: 'npm run start',
  //   url: 'http://127.0.0.1:3000',
  //   reuseExistingServer: !process.env.CI,
  // },
});

Ao adotar essa abordagem, você garante que sua equipe possa facilmente acessar, entender e agir com base nos resultados dos testes, promovendo um ciclo de desenvolvimento mais ágil e confiável. Essa prática não só melhora a qualidade do software, mas também reforça a confiança na entrega contínua.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será divulgado.


*