Para ingenieros senior, las pruebas web no se tratan de encontrar errores, sino de construir un sistema que los prevenga. Es una cuestión de arquitectura. Este post describe varios puntos clave a considerar al diseñar una estrategia de pruebas de nivel industrial, con un fuerte enfoque en las herramientas y protocolos que se encuentran en el corazón del ecosistema de Google Chrome.

Punto 1: Entiende el Panorama de los Protocolos de Automatización

En el nivel más bajo, la automatización de pruebas se trata de la comunicación con un navegador. Durante años, el estándar dominante ha sido WebDriver, un estándar abierto del W3C que Google apoya fuertemente a través de ChromeDriver. Proporciona una API estable y multiplataforma para la automatización de navegadores.

// Ejemplo usando selenium-webdriver con ChromeDriver
import { Builder, By, Key, until } from "selenium-webdriver";

(async function example() {
  let driver = await new Builder().forBrowser("chrome").build();
  try {
    await driver.get("http://www.google.com/ncr");
    await driver.findElement(By.name("q")).sendKeys("webdriver", Key.RETURN);
    await driver.wait(until.titleIs("webdriver - Google Search"), 1000);
  } finally {
    await driver.quit();
  }
})();

Sin embargo, las herramientas modernas a menudo utilizan un enfoque más directo y potente: el Protocolo de Chrome DevTools (CDP). Este es el mismo protocolo que la interfaz de usuario de Chrome DevTools utiliza para inspeccionar, depurar y perfilar el navegador. Es más rápido y ofrece un control más profundo que WebDriver, permitiéndote hacer cosas como interceptar peticiones de red, simular datos de sensores y trazar el rendimiento.

Punto 2: Aprovecha el CDP con Herramientas Modernas como Playwright

Playwright, un proyecto con profundas raíces en el equipo original de Chrome DevTools, fue construido desde cero sobre el CDP. Este es su superpoder. Al hablar el lenguaje nativo del navegador, evita la sobrecarga de la comunicación basada en HTTP de WebDriver, lo que resulta en pruebas más rápidas y fiables.

Esta conexión directa habilita características increíbles como el Playwright Trace Viewer. Cuando una prueba falla, genera un archivo de traza que puedes abrir en un navegador. Es un depurador que viaja en el tiempo para tu prueba, mostrándote una instantánea del DOM, logs de consola y peticiones de red para cada acción. Es como tener Chrome DevTools abierto para tu ejecución de CI.

Para hacer que las pruebas de Playwright sean escalables, utiliza el Page Object Model (POM):

LoginPage.ts

import { type Page, type Locator } from "@playwright/test";

export class LoginPage {
  readonly page: Page;
  readonly emailInput: Locator;
  readonly passwordInput: Locator;
  readonly signInButton: Locator;

  constructor(page: Page) {
    this.page = page;
    this.emailInput = page.getByLabel("Email");
    this.passwordInput = page.getByLabel("Password");
    this.signInButton = page.getByRole("button", { name: "Sign in" });
  }

  async login(email: string, pass: string) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(pass);
    await this.signInButton.click();
  }
}

login.spec.ts

import { test, expect } from "@playwright/test";
import { LoginPage } from "./LoginPage";

test("un usuario debería poder iniciar sesión", async ({ page }) => {
  const loginPage = new LoginPage(page);
  await page.goto("/login");
  await loginPage.login("user@test.com", "password");

  await expect(page).toHaveURL("/dashboard");
});

Punto 3: Considera Vectores de Pruebas Avanzados

La corrección funcional es solo una dimensión de la calidad. Para una estrategia verdaderamente robusta, considera estos vectores:

• Pruebas de Regresión Visual: Herramientas como Percy se integran con Playwright para tomar instantáneas del DOM y renderizarlas en diferentes navegadores, capturando errores visuales que las pruebas funcionales no detectan.

  import { test } from "@playwright/test";
  import percySnapshot from "@percy/playwright";
  
  test("la página de inicio de sesión debe verse correcta", async ({
    page,
  }) => {
    await page.goto("/login");
    await percySnapshot(page, "Login Page");
  });
  

• Pruebas de Contrato Dirigidas por el Consumidor: En un mundo de microservicios, usa Pact para asegurar que tu frontend y backend puedan comunicarse sin ejecutar costosas pruebas de integración a gran escala. El consumidor define un contrato y el proveedor debe demostrar que puede cumplirlo.

Punto 4: Haz del Rendimiento un Ciudadano de Primera Clase

El rendimiento no es algo que se añade al final; es una característica. Google ha defendido esta idea con herramientas como Lighthouse. Con Lighthouse CI, puedes automatizar la auditoría de rendimiento y establecer presupuestos para tus métricas clave (LCP, CLS, TBT).

Integrar esto en tu flujo de trabajo de GitHub Actions es sencillo:

# En tu flujo de trabajo de CI, después de un paso de despliegue
- name: Run Lighthouse CI
  run: |
    npm install -g @lhci/cli@0.13.x
    lhci autorun
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Esto ejecutará Lighthouse contra las URLs de tu despliegue y fallará la compilación si se exceden los presupuestos de rendimiento, previniendo regresiones antes de que lleguen a producción.

Al construir una estrategia en torno a estos puntos—entendiendo los protocolos, aprovechando las herramientas modernas y ampliando tu definición de calidad—puedes crear un sistema de pruebas que habilite la velocidad y la confianza.

Conclusión: Tu Próximo Paso

No intentes implementar todo esto mañana. Si vienes de un entorno legacy, mi recomendación es clara:

1. Migra un flujo crítico a Playwright y experimenta la estabilidad del CDP.
2. Automatiza un presupuesto de performance con Lighthouse CI para evitar el “bloat” de la aplicación.
3. Documenta los contratos, no solo el código.

La ingeniería de calidad no es un destino; es una disciplina continua. Construye sistemas que no solo encuentren errores, sino que hagan que cometerlos sea prácticamente imposible.

@khriztianmoreno

Until next time.