Garantizar que el software funciona correctamente no es opcional, y las arquitecturas limpias están diseñadas precisamente para facilitarlo. La testability —la facilidad con la que podemos verificar un programa— es uno de los atributos más valiosos de este enfoque, y entender cómo aplicar pruebas desde el primer día marca la diferencia entre un proyecto robusto y uno frágil.
Dos definiciones potentes enmarcan esta práctica: probar un programa es tratar de hacerlo fallar, o bien, probar es el arte de destruir algo constructivamente [0:18]. Ambas ideas nos recuerdan que el objetivo no es confirmar que todo va bien, sino buscar activamente los puntos débiles.
¿Qué es la pirámide de automatización de pruebas?
La pirámide de automatización de pruebas organiza las verificaciones en tres grandes niveles [1:08]:
- Pruebas unitarias: están en la base, verifican métodos y clases de forma muy específica.
- Pruebas de integración: incorporan dependencias entre componentes y validan su interacción.
- Pruebas de extremo a extremo: cubren flujos completos, desde la interfaz gráfica hasta la base de datos.
Esta estructura refleja una relación directa entre la posición en la pirámide y el costo de implementación. Las pruebas unitarias son rápidas de escribir, rápidas de ejecutar y baratas [1:52]. Por eso, idealmente deberíamos tener la mayor cantidad posible. A medida que subimos, las pruebas se vuelven más lentas, costosas y escasas. Las de extremo a extremo se reservan para flujos críticos, no para cubrir toda la aplicación.
¿Por qué las pruebas del modelo de dominio son unitarias?
Aquí es donde la arquitectura limpia brilla con fuerza. Las pruebas sobre el modelo de dominio son naturalmente unitarias porque este no depende de nadie [2:42]. Gracias a la regla de dependencias —que siempre van de afuera hacia adentro—, el dominio solo depende de sí mismo. No necesita bases de datos, frameworks ni servicios externos para ser verificado.
¿Cómo se estructura el testing en un proyecto con Spring Boot?
El ejemplo práctico utiliza Java con Spring Boot y Maven, donde la estructura de carpetas separa claramente el código fuente de los tests [3:06]. Dentro del paquete de pruebas se replica una organización similar al código principal:
- Pruebas del dominio separadas por aplicación y modelo.
- Posibilidad de agregar carpetas para la capa de infraestructura.
Esta estructura puede variar según las necesidades del equipo. Una alternativa válida es organizar por tipo de prueba —unitarias, de integración— en lugar de por capas [3:28]. Lo importante es mantener un orden claro que facilite encontrar y mantener cada test.
¿Cómo luce una prueba unitaria para un objeto de valor?
El ejemplo concreto verifica el comportamiento del objeto de valor Route [3:52]. Este objeto contiene un método llamado isValid que ejecuta validaciones sobre el origen y el destino de una ruta, determinando si está correctamente construida.
La prueba crea instancias de Route con distintas combinaciones de parámetros y comprueba que la validación responda correctamente en cada caso [4:08]. Se utiliza JUnit como framework de pruebas, aunque cualquier herramienta equivalente cumple el mismo propósito.
Aunque parezca una verificación sencilla, su valor es enorme. Cuando múltiples personas modifican el código y el ritmo de cambios se acelera, incluso reglas aparentemente simples pueden romperse sin que nadie lo note [4:30]. Las pruebas unitarias actúan como una red de seguridad permanente.
¿Qué ventaja real ofrece separar el modelo de dominio para el testing?
Tener la lógica de negocio aislada en el modelo de dominio —y no mezclada con la capa de aplicación— permite verificar cada pieza de forma independiente [4:58]. Objetos como Flight, que también contienen reglas de negocio, se benefician de la misma separación: se prueban de manera unitaria, rápida y sin dependencias externas.
Esta decisión arquitectónica convierte las pruebas en algo accesible desde el inicio del proyecto, no en una tarea que se posterga indefinidamente. La capa de aplicación y las pruebas de integración entran en juego cuando necesitamos verificar escenarios más complejos con dependencias reales.
Si ya aplicas pruebas unitarias en tus proyectos, comparte qué estrategias te han funcionado mejor para organizar los tests dentro de una arquitectura limpia.
