Paralelismo, reportes y CI

Paralelo con pytest-xdist

pip install pytest-xdist
pytest -n 4  # 4 workers, cada uno con su navegador

Requisito no negociable: tests independientes. Si dos tests comparten un usuario o un registro, en paralelo se pisan y tendrás fallos aleatorios que nadie podrá reproducir. Cada test crea sus datos (idealmente por API) y no asume orden.

Reportes que alguien mira

pip install pytest-html
pytest -n 4 --html=report.html --self-contained-html

Y screenshot automático al fallar, con un hook en conftest.py:

import pytest


@pytest.hookimpl(hookwrapper=True)
def pytest_runtest_makereport(item, call):
    outcome = yield
    report = outcome.get_result()
    if report.when == "call" and report.failed:
        driver = item.funcargs.get("driver")
        if driver:
            driver.save_screenshot(f"screenshots/{item.name}.png")

La suite en GitHub Actions

# .github/workflows/e2e.yml
name: E2E
on: [push, pull_request]
jobs:
  selenium:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install -r requirements.txt
      - run: pytest -n 4 --html=report.html --self-contained-html
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: evidencia
          path: |
            report.html
            screenshots/

Chrome ya viene instalado en ubuntu-latest y Selenium Manager resuelve el driver: no necesitas contenedores ni servicios extra para empezar.

Flaky tests: política, no resignación

En CI aparecerá el test que "a veces falla". La política sana:

1. Cuarentena inmediata (@pytest.mark.flaky_quarantine + deselección en CI) — un flaky en la suite principal entrena al equipo a ignorar el rojo.
2. Diagnóstico con presupuesto: la mayoría son esperas mal hechas o datos compartidos.
3. Si no se arregla, se borra. Un test en cuarentena permanente es mentira institucionalizada.

Cierre del curso

Tienes un framework Selenium completo: selectores robustos, esperas correctas, POM, paralelo y CI. Dos caminos naturales desde aquí: Playwright pro para el stack moderno, o QA con IA para multiplicar tu velocidad escribiendo y manteniendo esta misma automatización.

Ejercicio final

Sube tu framework del ejercicio anterior a un repo con el workflow de GitHub Actions. Criterio de éxito: un push con un test roto debe poner el check rojo y adjuntar el screenshot como artefacto.