Prueba los píxeles: control de calidad por capturas para un equipo pequeño

Lo adoptamos por las malas: después de lanzar regresiones visuales que una sola captura habría cazado. Un panel esmerilado que salía pálido sobre fondos oscuros. Un menú que se dibujaba pero no se podía pulsar. Un campo de búsqueda que a lo ancho de un móvil existía como una tira de 65 píxeles. Todos pasaron una batería de pruebas en verde, porque la batería probaba funciones y los fallos vivían en los píxeles.

El montaje es más pequeño de lo que crees

El nuestro es un entorno local lleno de datos falsos convincentes, un inicio de sesión sin interfaz cuya sesión se guarda en disco para que nada lo frene y un bucle: páginas por temas por tamaños de pantalla. Escritorio y móvil, claro y oscuro, todas las pantallas que importan. Todo cabe en un script corto, y un barrido completo produce una carpeta de imágenes en unos minutos.

1import { chromium } from 'playwright';2 3const browser = await chromium.launch();4const ctx = await browser.newContext({5  storageState: 'auth.json', // login once, reuse everywhere6  viewport: { width: 1440, height: 900 },7});8const page = await ctx.newPage();9 10for (const [name, url] of PAGES) {11  await page.goto(BASE + url, { waitUntil: 'load' });12  for (const theme of ['light', 'dark']) {13    await page.evaluate((t) =>14      document.documentElement.setAttribute('data-theme', t), theme);15    await page.screenshot({ path: `shots/${name}-${theme}.png`, fullPage: true });16  }17}

Capturas más pruebas

Las imágenes cazan lo que cazan los ojos. Para los fallos de interacción quieres que declare el navegador. Dos líneas hacen casi todo el trabajo: elementFromPoint en el centro de un control te dice qué recibiría realmente el clic, y getBoundingClientRect te dice si el control cabe de verdad en el tamaño de pantalla que dice soportar. Ahora comprobamos las dos cosas en todo lo que nos ha quemado alguna vez.

1// Is the menu item really clickable, or is something invisible covering it?2const hit = await page.evaluate(() => {3  const el = document.querySelector('[role="menuitem"]');4  const r = el.getBoundingClientRect();5  const top = document.elementFromPoint(r.x + r.width / 2, r.y + r.height / 2);6  return el === top || el.contains(top);7});8 9// Does the search input actually fit a 390px phone?10const fits = await page.evaluate(() => {11  const r = document.querySelector('input[name="q"]').getBoundingClientRect();12  return r.right <= window.innerWidth && r.width > 200;13});

Los dos temas, siempre

Los fallos de modo oscuro son una categoría aparte porque se esconden de quien trabaja siempre en un solo tema. Un relleno casi blanco escrito a mano parece intencionado en una página clara y radiactivo en una oscura. Cambiar el atributo del tema dentro de la misma visita cuesta una línea y duplica tu cobertura. Damos por no probada cualquier pantalla que no se haya fotografiado en los dos temas.

Qué caza

• Fallos de contexto de apilamiento: dibujado, visible y sin poder pulsarse. Esto solo lo ve una prueba de impacto.
• Fugas de tema: superficies claras brillando en páginas oscuras, gráficos que desaparecen, ilustraciones con el fondo incrustado.
• Desbordes en móvil: barras fijas tapando el contenido, campos recortados a una tira, titulares cortados a media frase.
• Textos en su contexto: el recorte, la contradicción, la frase que ningún linter va a señalar.

Nada de esto sustituye a la batería de pruebas unitarias. La batería demuestra que las cuentas del dinero salen; las capturas demuestran que una persona puede llegar al botón que las dispara. Un equipo pequeño no tiene departamento de calidad, pero una carpeta de capturas recientes revisadas antes de cada lanzamiento es una imitación bastante decente. La prueba es mirarlas.

Las pruebas pasan es una afirmación sobre tus funciones. La captura es una afirmación sobre tu producto.