Testing en frontend: qué probar y qué no

El testing se ha convertido en una pieza clave del desarrollo frontend, pero no todos los elementos de una UI merecen el mismo nivel de pruebas. En este artículo te explico, de forma práctica y cercana, qué deberías testear en tu proyecto y qué puedes dejar fuera, sin comprometer la robustez ni la velocidad del pipeline.

Qué probar

En general, hay tres áreas que siempre deben estar cubiertas por tests automatizados:

Lógica de negocio en el cliente: cualquier cálculo, transformación de datos o decisión que se haga en JavaScript antes de enviar la petición al servidor.
Componentes críticos de la UI: aquellos que gestionan estado, realizan validaciones o interactúan con APIs externas.
Flujos de usuario completos: recorridos que combinan varios componentes y que representan casos de uso importantes (registro, checkout, envío de formularios).

Un ejemplo clásico es un componente de formulario que valida campos y llama a una API. Aquí tienes un test con @testing-library/react que cubre la lógica de validación y la interacción del usuario:

import { render, screen, fireEvent } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import LoginForm from './LoginForm';

test('muestra error si el email es inválido', async () => {
  render(<LoginForm />);

  const emailInput = screen.getByLabelText(/email/i);
  const submitBtn = screen.getByRole('button', { name: /entrar/i });

  await userEvent.type(emailInput, 'no-es-un-email');
  fireEvent.click(submitBtn);

  expect(screen.getByText(/formato de email incorrecto/i)).toBeInTheDocument();
});

En este bloque probamos la validación de formato sin necesidad de tocar la capa de red. El test es rápido, fiable y se ejecuta en milisegundos.

Qué no probar

Hay cosas que, aunque parezcan tentadoras, no aportan valor real al proceso de testing y pueden ralentizarlo considerablemente:

Estilos CSS y clases: a menos que estés usando una solución CSS‑in‑JS que genere lógica, verificar que un className está presente no garantiza nada sobre la apariencia final.
Implementaciones de librerías externas: si una dependencia ya está cubierta por sus propios tests, no necesitas volver a testear su comportamiento interno.
Componentes puramente presentacionales que no tienen lógica ni efectos secundarios. En su lugar, confía en pruebas de snapshot o, mejor aún, en pruebas visuales manuales.

En vez de crear tests para estos casos, enfócate en pruebas de integración que comprueben que el componente se renderiza y responde a la interacción del usuario.

Consejos para decidir el nivel de cobertura

1. Prioriza por riesgo: si un fallo puede romper el flujo de compra o exponer datos sensibles, ese camino merece pruebas exhaustivas.

2. Aplica la regla del 80/20: el 20 % de tu código suele generar el 80 % de los errores. Identifica esas áreas críticas y cubre esas rutas.

3. Mantén los tests rápidos: un test que tarda más de 500 ms empieza a ser un obstáculo en la integración continua. Si un test es lento, revisa si estás haciendo llamadas reales a la API o a la base de datos.

4. Refactoriza con pruebas: escribe primero un test que falle, implementa la funcionalidad mínima y refactoriza. Esto te ayuda a mantener la cobertura alineada con la complejidad real del código.

Herramientas recomendadas

Para llevar a cabo una estrategia de testing equilibrada en el frontend, estas son mis favoritas:

Jest: runner y aserciones con gran ecosistema.
@testing-library/react: fomenta pruebas basadas en la experiencia del usuario.
MSW (Mock Service Worker): permite simular respuestas de API sin tocar el backend.
Playwright o Cypress: pruebas end‑to‑end que cubren flujos completos.

Combina pruebas unitarias para la lógica y componentes críticos, pruebas de integración para flujos de negocio y pruebas E2E para los caminos de usuario más importantes. Así lograrás una cobertura efectiva sin sobrecargar tu pipeline.

En resumen, no se trata de testear todo, sino de testear lo que realmente importa. Aplica criterios de riesgo, mantén los tests rápidos y usa las herramientas adecuadas. Con esa mentalidad, tu código será más fiable y tus despliegues más seguros.