Testing en frontend: qué probar y qué no

El testing es una de esas actividades que, cuando se hace bien, nos ahorra tiempo y nos da confianza al lanzar cambios. Pero no todo necesita una batería de pruebas exhaustiva. En este artículo vamos a ver, de forma práctica, qué deberías testear en el frontend y qué puedes omitir sin arriesgar la calidad del producto.

1. ¿Para qué testear en el frontend?

En el mundo de las SPA (Single Page Applications) y los componentes reutilizables, los tests nos ayudan a:

• Detectar regresiones antes de que lleguen al usuario.
• Documentar el comportamiento esperado de los componentes.
• Facilitar refactorizaciones seguras.

Sin embargo, la clave está en enfocarse en lo que realmente aporta valor.

2. Qué deberías probar

En esta sección listamos los tipos de pruebas que, según mi experiencia, aportan mayor retorno de inversión.

• Lógica de negocio aislada: funciones puras, hooks personalizados o reducers. Son fáciles de testear con jest y su cobertura se traduce en menos bugs.
• Componentes críticos: aquellos que gestionan estados complejos, realizan cálculos o manejan datos sensibles (por ejemplo, un carrito de compra).
• Flujos de usuario: recorridos que atraviesan varios componentes, como iniciar sesión, añadir un producto al carrito o completar un formulario.
• Accesibilidad básica: verifica que los elementos tengan atributos aria- correctos y que el teclado pueda navegar por la UI.
• Integración con APIs externas: simula respuestas con msw (Mock Service Worker) para asegurarte de que tu capa de datos maneja errores y estados de carga adecuadamente.

3. Qué no deberías probar

Hay tentaciones comunes que, en la práctica, generan más ruido que valor.

• Estilos CSS y clases: a menos que trabajes con un framework CSS que genere lógica (por ejemplo, Tailwind con variantes dinámicas), comprobar que un div tenga la clase bg-primary rara vez detecta errores reales.
• Implementación de librerías de terceros: confiar en que react-router o formik funcionan según su documentación es más razonable que escribir tests que reproduzcan su código interno.
• Detalles de layout: la posición exacta de un elemento o su pixel‑perfect alignment suele ser responsabilidad del diseñador y de pruebas visuales automatizadas (por ejemplo, Percy), no de unit tests.
• Comportamiento de navegadores: pruebas de compatibilidad deben hacerse en entornos reales (BrowserStack, Cypress) y no en unit tests.

4. Ejemplo práctico: testear un componente de lista filtrable

Supongamos que tenemos un componente FilterableList que muestra una lista de usuarios y permite filtrarla por nombre. Queremos probar que:

• Se renderiza la lista completa al iniciar.
• Al escribir en el input, la lista se actualiza mostrando solo los coincidencias.

Usaremos Jest y React Testing Library:

import { render, screen, fireEvent } from '@testing-library/react';
import FilterableList from './FilterableList';

const users = [
  { id: 1, name: 'Ana' },
  { id: 2, name: 'Luis' },
  { id: 3, name: 'María' },
];

test('muestra la lista completa al montar', () => {
  render(<FilterableList items={users} />);
  expect(screen.getAllByRole('listitem')).toHaveLength(3);
});

test('filtra la lista según el texto introducido', () => {
  render(<FilterableList items={users} />);
  const input = screen.getByPlaceholderText('Buscar…');
  fireEvent.change(input, { target: { value: 'an' } }); // coincide con Ana y María
  const items = screen.getAllByRole('listitem');
  expect(items).toHaveLength(2);
  expect(items[0]).toHaveTextContent('Ana');
  expect(items[1]).toHaveTextContent('María');
});

En este caso, estamos probando la lógica de filtrado (una función pura dentro del componente) y el efecto colateral en la UI. No nos preocupamos por los estilos del input ni por la implementación interna de Array.filter.

5. Consejos para mantener los tests útiles

• Mantén los tests pequeños y enfocados: un test debe validar una única cosa.
• Usa nombres descriptivos que expliquen el comportamiento esperado.
• Evita pruebas frágiles: en vez de buscar un elemento por su clase, usa roles, textos accesibles o atributos data-testid bien pensados.
• Revisa la cobertura pero no persigas el 100% a cualquier precio; prioriza la calidad sobre la cantidad.
• Integra los tests en el CI para que cualquier fallo detenga el despliegue.

Al final, la meta es que el conjunto de pruebas sea una red de seguridad que permita iterar rápido sin miedo a romper nada. Si sigues estos principios, sabrás exactamente qué probar y qué dejar fuera, optimizando tiempo y manteniendo la calidad de tu frontend.