Una vez pregunté a un programador experimentado y conocido en la industria: Puede un sistema mediano / grande estar "bien hecho" sin el uso de testing automatizado?
El respondió que sí. Personalmente he conocido muy buenos programadores que, aún sin usar testing en lo absoluto, al destacar en la "consistencia" de sus diseños y convenciones de trabajo, entregaban buenas piezas de software. La pregunta que surge es: Es esto aplicable a un equipo de 5, 10 o más personas? Difícil responder sí.
Eso nos lleva a la realidad de que eminencias de la industria dirán que no se puede pensar en la idea de un sistema bien realizado sin el apoyo de una buena suite de tests.
Es innegable que, cuando contamos con el respaldo de tests automatizados, no solo el sistema con el que trabajamos es más confiable, sino que el uso de los mismos nos obliga a mejorar nuestros diseños de software.
Por esa razón, comparto algunas preguntas junto a sus modestas respuestas para los que recién se acercan a este mundo:
1 - Por qué debo testear?
Los tests nos protegen contra los bugs (sí, es muy posible que estés lidiando con muchos bugs y por eso te estés acercando al mundo del testing), nos ahorra tiempo en el corto o mediano plazo, nos ayudan a pensar más en el diseño de nuestra sistema, en muchos casos nos suben el nivel técnico y por ende nos profesionaliza. Hay que detenerse un poco a pensar en todos los beneficios que esto conlleva, no son pocos.
2 - Cuáles son los tipos de tests más usados?
Test de Aceptación ó e2e (End to End): Estos son aquellos que probarán nuestro sistema desde cada punto de entrada deseado, tratando de que este recorra la mayor cantidad posible del circuito de nuestro sistema. El objetivo es que interactúe con todos los elementos necesarios, conectándose a sistemas externos y levantado todos los servicios necesarios para su funcionamiento como si lo estuviese usando el "usuario final".
Test de Integración: Este tipo de test probará como se integra nuestro sistema con otros sistemas externos. Un ejemplo es la base de datos. Otro ejemplo sería que un módulo de nuestro sistema se conecta a otro. Prueba circuitos más específicos y normalmente más cortos que los e2e.
Test Unitario: Este tipo de test, como su nombre lo indica, probará unidades de comportamiento de forma independiente. Tiene como propósito concentrarse en el modelo de negocio de nuestro sistema en vez de en cómo se integra a otros servicios. Trata de atacar a la lógica fundamental, el core del negocio, del sistema con el que trabajamos.
3 - Cómo deben ser los test?
Deben ser simples, puntuales, fáciles de entender, descriptivos. Un solo método debería poder resolver toda la lógica, no debería esconderse ninguna lógica. No debe saber muchos detalles de implementación del componente ó sistema bajo test. Los tests suelen tener una misma fisionomía, una separación en tres grandes pasos (AAA): Arrange (Armado), Action (Acción), Assert (Afirmar).
4 - Qué debo testear?
Debemos esforzarnos por testear, de forma directa o indirecta todos los flujos de nuestro sistema. El énfasis debe ser puesto en la lógica de negocio, en las piezas de nuestro software más importantes.
Programar tests lleva tiempo, al principio no es fácil, y puede que lo hayamos intentado en más de una ocasión sin éxito. La clave está en perseverar y en entender que vale la pena el esfuerzo.
Top comments (0)