Soft Assertions en Playwright: cuándo usarlas (y cuándo no)

Hay una feature de Playwright que, cuando la descubrís por primera vez, te parece una maravilla. Y después, si la usás mal, te parece una quilombo. Estoy hablando de las soft assertions y si, las he visto usadas de las dos formas.

En este post te cuento qué son, cómo funcionan, te doy ejemplos concretos y, lo más importante, te doy mi opinión honesta de cuándo tiene sentido usarlas y cuándo es mejor no tocarlas.

Primero lo básico: ¿qué es una assertion "normal"?

Cuando en Playwright escribís:

await expect(page.locator('.precio')).toHaveText('$99');

Si ese elemento no tiene el texto $99, el test explota ahí mismo. Se corta. No sigue. Game over.

Eso es una hard assertion: o pasa o no pasa, y si no pasa, el test muere en el acto.

¿Y qué es una soft assertion entonces?

Una soft assertion hace la misma verificación, pero no detiene la ejecución del test si falla.

await expect.soft(page.locator('.precio')).toHaveText('$99');
await expect.soft(page.locator('.descuento')).toBeVisible();
await expect.soft(page.locator('.boton-compra')).toBeEnabled();

// recién acá verificamos si hubo algún fallo
expect(test.info().errors).toHaveLength(0);

¿Lo ves? El test sigue corriendo aunque una o más assertions fallen. Acumula todos los errores y te los muestra juntos al final.

Un ejemplo más concreto

Imaginemos que estamos testeando una página de producto de un e-commerce. Queremos verificar varios elementos visuales de una sola vez:

import { test, expect } from '@playwright/test';

test('verificación completa de la página de producto', async ({ page }) => {
  await page.goto('https://mi-tienda.com/producto/zapatillas-runner');

  // Verificamos varios elementos sin cortar el test si alguno falla
  await expect.soft(page.locator('h1')).toHaveText('Zapatillas Runner Pro');
  await expect.soft(page.locator('.precio')).toContainText('$89.99');
  await expect.soft(page.locator('.rating')).toBeVisible();
  await expect.soft(page.locator('.boton-agregar-al-carrito')).toBeEnabled();
  await expect.soft(page.locator('.imagen-principal')).toBeVisible();
  await expect.soft(page.locator('.descripcion')).not.toBeEmpty();
});

Con hard assertions, si el título falla, no sabés nada del precio, del rating ni del botón. Tenés que arreglar y volver a correr.

Con soft assertions, una sola ejecución te da el panorama completo de qué está roto y qué no.

¿Cuándo tiene sentido usar soft assertions?

1. Cuando estás verificando múltiples elementos independientes entre sí

Si tenés una página con 8 elementos que querés chequear y ninguno depende del otro para existir, las soft assertions son tus amigas. Un solo test run, un solo reporte, toda la información junta.

2. En tests de smoke o sanity check

Cuando necesitás un pantallazo rápido del estado general de la app. "¿Qué está roto hoy en producción?" es una pregunta que las soft assertions responden mucho más eficientemente.

3. Cuando el costo de volver a correr el test es alto

Si tu suite tarda 40 minutos en correr, tener que correrla tres veces para descubrir tres problemas diferentes es un desperdicio enorme. Soft assertions te permiten encontrar más cosas en un solo run.

4. En validaciones de UI o diseño

¿Estás chequeando que todos los textos de una página estén bien traducidos? ¿Que todos los íconos estén visibles? ¿Que una grilla de productos tenga todos los campos? Soft assertions, sin dudarlo.

¿Cuándo NO usarlas?

Acá viene la parte que me parece más importante y que mucha gente ignora.

1. Cuando los pasos tienen dependencia entre sí

Si el paso 2 depende de que el paso 1 haya salido bien, no tiene ningún sentido usar soft assertion en el paso 1. Si el login falla, ¿qué sentido tiene verificar el dashboard? Ninguno. El test va a tirar errores confusos y vas a perder el tiempo.

// ❌ Esto no tiene sentido
await expect.soft(page.locator('#usuario')).toBeVisible();
await page.fill('#usuario', 'pato@freerangetesters.com'); // puede explotar acá
await expect.soft(page.locator('#password')).toBeVisible();

2. Cuando querés que el test falle rápido y fuerte

Hay situaciones donde querés ruido. Un fallo estridente que nadie pueda ignorar. Si una funcionalidad crítica está rota, no querés un reporte prolijo al final: querés que el test explote y alerte a todo el mundo de inmediato. Para eso existen las hard assertions.

3. En flujos transaccionales

Pago, checkout, creación de cuenta, envío de formularios. Si algo falla en el medio de un flujo así, tiene cero sentido seguir ejecutando los pasos siguientes. Las soft assertions en estos casos generan falsos negativos y reportes confusos.

4. Cuando abusás de ellas para tapar deuda técnica

Este es el más importante y el que menos se habla. Si empezás a usar soft assertions para que "al menos el test no falle del todo" cuando hay cosas rotas... estás usando la herramienta para esconder problemas, no para encontrarlos. Eso no es testing, es magia negra.

Un tip de implementación

Playwright acumula los errores de las soft assertions en test.info().errors. Podés usarlo para hacer cosas interesantes:

test('chequeo visual completo', async ({ page }) => {
  await page.goto('/dashboard');

  await expect.soft(page.locator('.widget-ventas')).toBeVisible();
  await expect.soft(page.locator('.widget-usuarios')).toBeVisible();
  await expect.soft(page.locator('.widget-conversiones')).toBeVisible();

  // Si hubo errores, los logueamos con más detalle
  const errores = test.info().errors;
  if (errores.length > 0) {
    console.log(`Se encontraron ${errores.length} problema(s) en el dashboard`);
  }
});

El resumen que necesitás

Las soft assertions son una herramienta poderosa cuando tenés claro para qué sirven. Te permiten obtener más información en menos tiempo cuando estás chequeando cosas independientes entre sí.

Pero son una trampa cuando las usás en flujos con dependencias, o peor, cuando las usás para que "el test no falle tanto". El peor caso es, para mi, cuando las usan para "testear un montón de cosas que nada que ver en un mismo test".

Como toda herramienta: el problema no es la herramienta, es no entender cuándo usarla. Y si querés aprender a usarla como dios manda, te recomiendo nuestro curso de Playwright con TypeScript que aprendés esto y muchísimo más.

¿Ya las estabas usando en tus proyectos? ¿O recién las descubriste? Te leo en los comentarios.