Skip to main content

Probando la lógica de negocio: pruebas unitarias en el backend

El lugar donde se toman decisiones: pruebas unitarias de lógica de negocio​

En backend, la lógica de negocio es la capa que define el significado real del sistema.

Aquí no se habla de rutas, ni de Express, ni de bases de datos. Aquí se decide:

  • Qué datos son aceptables
  • Qué acciones están permitidas
  • Qué cálculos son correctos
  • Qué errores deben aparecer y cuándo

Si esta capa falla, todo lo demás puede “funcionar” y aun así estar mal.

La lógica de negocio es el reglamento interno del juego.

Las pantallas, menús y controles pueden verse bien, pero si el reglamento permite vidas infinitas o puntuaciones inválidas, el juego está roto desde dentro.

Las pruebas unitarias existen para validar este reglamento de forma aislada y precisa.

Qué significa “lógica de negocio” en una aplicación web​

En una aplicación real, la lógica de negocio vive en funciones o servicios que toman decisiones. No dependen del navegador ni del servidor. Solo reciben datos y devuelven resultados.

Validación​

Reglas que deciden si algo es aceptable:

  • Email y contraseña con criterios claros
  • Normalización de datos (espacios, mayúsculas, formato)
  • Restricciones por país o tipo de usuario

Cálculo​

Reglas numéricas que no pueden fallar:

  • Totales de carrito con impuestos y descuentos
  • Comisiones y redondeos
  • Límites máximos o mínimos

Decisión​

Reglas que controlan lo que está permitido:

  • Quién puede borrar o editar
  • En qué estado se permite una acción
  • Compatibilidad entre acciones y estados

Transformación​

Reglas que adaptan datos:

  • Convertir input del cliente en modelos internos
  • Generar respuestas coherentes
  • Producir eventos o registros de auditoría

Cuanto más “pura” sea esta función —misma entrada, misma salida, sin tocar el exterior— más fácil será probarla y más fiables serán sus tests.

Qué hace especial a una prueba unitaria​

Una prueba unitaria no prueba el sistema entero. Prueba una pieza concreta, sin ruido.

Es como comprobar una norma interna de una empresa sin entrar al edificio, sin hablar con recepción y sin usar el sistema informático. Solo importa la regla y su decisión.

Para que eso funcione, una buena prueba unitaria cumple varios requisitos claros.

Requisitos de una prueba unitaria sólida​

Aislamiento​

No depende de:

  • Express
  • HTTP
  • base de datos
  • red
  • reloj real
  • estado compartido

La prueba solo conoce la función que se está evaluando.

Determinismo​

El resultado es siempre el mismo. Si hay tiempo, aleatoriedad o efectos externos, se controlan o simulan.

Rapidez​

Debe ejecutarse en milisegundos. El objetivo es poder ejecutarlas constantemente sin fricción.

Legibilidad​

La prueba debe leerse como una frase:

“Dado esto, espero esto”.

Fallos claros​

Cuando falla, debe ser evidente:

  • Qué entrada se usó
  • Qué se esperaba
  • Qué regla se rompió

Si entender el fallo requiere depurar media aplicación, el test está mal diseñado.

El patrón mental que lo ordena todo: Arrange – Act – Assert​

Las pruebas unitarias siguen siempre la misma estructura lógica. Mantenerla estable convierte los tests en documentación ejecutable.

Arrange​

Preparas las entradas y el contexto necesario.

Act​

Ejecutas la función que quieres validar.

Assert​

Compruebas el resultado o el error esperado.

Si estos pasos se mezclan, el test deja de explicar una regla y se convierte en un script confuso y frágil.

Por qué las pruebas unitarias son la base del backend​

Las pruebas unitarias son la primera línea de defensa:

  • Detectan errores antes de que lleguen a rutas o usuarios
  • Permiten refactorizar sin miedo
  • Hacen explícitas las reglas del sistema

Cuando la lógica de negocio está bien cubierta por pruebas unitarias, el backend gana algo clave: previsibilidad.

Y un backend previsible es el requisito mínimo para construir sistemas fiables, escalables y mantenibles a largo plazo.