Compartir

Garantía de calidad del software con TDD (Test Driven Development)

25/10/22 - 10 minutos de lectura

Uno de los grandes retos a los que todavía se enfrentan los equipos de desarrollo de software es garantizar la calidad. En los proyectos que utilizaban el método tradicional en Cascada, teníamos una fase bien definida donde se realizaban las pruebas del software. El problema es que esta era una fase tardía y, a menudo, se pasaba por alto o ignoraba por la presión que ejercía la fecha límite.

En este artículo hablaremos sobre Test Driven Development (TDD), que es una práctica de desarrollo de software en la cual las pruebas se piensan y escriben antes que el código comercial. Con ello, aumentamos considerablemente la calidad de un producto y consecuentemente la satisfacción de nuestros clientes y usuarios.

¿Hay alguna manera de probarlo antes de comenzar a desarrollarlo?

Sí, la calidad de un software es responsabilidad de todos. Incluso antes de comenzar su desarrollo. Product Owner, Equipo de Desarrollo y Scrum Master deben trabajar juntos para garantizar que esto suceda.

Para los siguientes tópicos, usaremos como ejemplo un Equipo que desarrolla un sitio web de e-commerce. Durante una reunión, el director de marketing comunica lo siguiente: el día 15 de este mes, lanzaremos la promoción de Navidad en la que otorgaremos descuentos de la siguiente manera: las compras inferiores a BRL 500,00 permanecen como están hoy, sin descuento. Ya las compras superiores a BRL 500,00 reciben un 10% de descuento. El Product Owner escribió entonces la siguiente historia de usuario: Yo, como comprador, quiero obtener un descuento para ahorrar mi paga extra en compras navideñas.

Criterios de Aceptación

Para cada elemento del backlog, el Equipo debe definir los criterios de aceptación. Y deben hacerlo antes del inicio de desarrollo para evitar sorpresas al final y las célebres frases que generan enfrentamientos entre Equipo de Desarrollo y Product Owner: "No lo dijiste antes", "No lo sabíamos", " No implementasteis tal cosa", etc.

Cabe destacar que estos criterios determinan cuál es el comportamiento del software esperado por el Product Owner, usuarios, clientes o stakeholders. 

Dan North introdujo un formato interesante para escribir los criterios de aceptación en 2006. Aborda algunos aspectos importantes para una buena prueba. En qué escenario y acción se encuentra este usuario y qué resultado recibirá. El formato es:

Dado que <Condiciones necesarias>

Cuándo <evento>

Entonces <resultado>

Los criterios de aceptación de la historia que nos ocupa podrían ser:

Criterio de Aceptación 01

Dado que el cliente realizó una compra de BRL 499,99

Cuándo cerrar la compra

Entonces no se le otorga descuento Y el precio final de compra es de BRL 499,99.

Criterio de Aceptación 02

Dado que el cliente realizó una compra de BRL500,00

Cuándo cerrar la compra

Entonces recibe un 10% de descuento Y el precio de compra final pasa a ser de BRL 450,00.

Ten en cuenta que los criterios describen claramente al equipo cuál es el descuento escrito en la historia de usuario. En este caso, también ayudan a definir el valor límite de la franja de descuento.

Test Driven Development (TDD)

Para demostrar cómo funciona TDD, crearemos un proyecto Java simple usando el IDE Eclipse. Recordando que TDD no es específico de Java y funciona en varios lenguajes de programación.

Preparando

Para crear un proyecto Java, ve a File → New → Java Project. Para este ejemplo creamos un proyecto llamado e-commerce.

Para hacer TDD, también deberás agregar el marco de trabajo JUnit a tu Classpath haciendo clic en el botón derecho sobre tu proyecto → Build Path → Add Libraries → JUnit → Elige la versión 4 o 5.

Configuremos la siguiente estructura del proyecto.

Garantía de calidad del software con TDD (Test Driven Development) 1
Ejemplos de Directorios y paquetes de aplicaciones.

A separar las cosas

No mezcles el código de prueba con el código comercial. El código de prueba no entrará en producción. Estamos separando las clases de negocio en source folder src/main/java y las clases de prueba en src/test/java.

En nuestro ejemplo, durante la planificación, el equipo acordó que la funcionalidad que resuelve la historia se implementaría en la clase CalculadoraDescuentos. Crearán el método llamado “calcular” que toma el total de la compra y devuelve la parte descontada. Sin embargo, como nuestro equipo usa TDD, nuestra primera creación será la clase CalculadoraDescuentosPrueba en el paquete br.com.k21.e-commerce.control.test.

Garantía de calidad del software con TDD (Test Driven Development) 2
Calculadora DescuentoPrueba inicial

Crearemos la primera prueba con el primer criterio de aceptación.

Garantía de calidad del software con TDD (Test Driven Development) 3

Antes de continuar, hay algunos puntos importantes que debemos abordar.

Nombres significativos

A menos que estés trabajando en un lenguaje con restricciones en la longitud del nombre de métodos o variables como Cobol, no escatimes en letras al hacer tus declaraciones. Cuando otro programador se fije en tu prueba, deberá comprender qué hace, cuáles son las variables de entrada y salida, para qué sirven las variables de entrada y salida y qué método se implementó.

El código de prueba debe ser muy simple para que se convierta en documentación. Si tienes que comentar las pruebas, comienza a pensar si el código comercial no está muy acoplado o si la complejidad es demasiado alta.

“Programa siempre como si el tipo que guardará tu código fuera un psicópata violento que supiera dónde vives”.

James F. Woods, 1991

Arrange Act Assert (AAA)

La estructura de una buena prueba se compone de 3 partes bien definidas conocidas como: Arrange, Act y Assert (AAA). 

Arrange es la parte de organización y preparación de la prueba.

Aquí ponemos las variables que necesitaremos en la prueba o cualquier línea de código necesaria para que se ejecute la acción que queremos probar.

Act es la acción. Aquí ejecutamos el método que queremos probar en la clase de negocio.

Assert es la afirmación. Aquí comprobamos si el valor esperado es idéntico al valor calculado.

Baby Steps

En TDD también nos gusta Baby Steps (pasos de bebé). Si eres programador y has visto nuestros criterios de aceptación, probablemente hayas pensado en todas las condiciones necesarias para cumplir con los criterios. Tu deseo ahora es poner los IF en la clase empresarial. ¡NO HAGAS ESO!

Ve con calma. En contextos reales, tendrás mucho más que 3 criterios de aceptación. Poner todo en la clase de negocio de una vez te hará perder la noción de lo que se ha probado y lo que no. Si realizas las pruebas más tarde, puedes terminar con un falso positivo. Algo que no funciona correctamente, pero no has podido cubrir las condiciones con una prueba.

Como puedes ver, la clase de negocio no se creó y, por lo tanto, Eclipse informa un error en la línea 13. Si ejecutas las pruebas (haz clic con el botón derecho en  proyect → Run As → JUnit Test), obtendrás un error: java.lang .Error: Lo que significa que CalculadoraDescuentos no existe.

Garantía de calidad del software con TDD (Test Driven Development) 4

Vamos a crearla. Haz clic con el botón derecho en el paquete br.com.k21.e-commerce.control en source folder src/main/java → New → Class → Name: CalculadoraDescuentos → Finish.

Regresa a la clase CalculadoraDescuentosPrueba e impórtalo a CalculadoraDescontos. Ten en cuenta que el error ahora se ha movido a la línea 21. Si vuelves a ejecutar las pruebas, obtendrás el error: java.lang.Error: Unresolved compilation problem: The method calcular(double) is undefined for the type CalculadoraDescontos. Lo que significa que el método de cálculo aún no existe en la calculadora.

JUnit indicando erro, pois o método Calcular não existe em CalculadoraDescontos

Vamos a crear el método de cálculo en CalculadoraDescuentos. Inicialmente se ve así:

Método Calcular em CalculadoraDescontos

Ciclo de TDD: Red, Green, Refactor

Garantía de calidad del software con TDD (Test Driven Development) 5

Red (Rojo) significa que la primera vez que ejecutamos la prueba, no puede pasar. Tiene que cometer un error. Esto te ayudará a evitar falsos positivos.

Green (Verde). Implementarás el código comercial, lo suficiente para que pase la prueba. Evita hacer cosas extravagantes al principio.

Refactor (Refactorizar). Los pasos rojo y verde crean una especie de pantalla de protección que garantiza que tu código no se comporte de forma inesperada. Desde aquí podemos refactorizarlo para que quede limpio.

Ejecuta la prueba y obtendrás un error: java.lang.AssertionError: expected:<499.99> but was:<-1.00>.  Lo que significa que esperábamos un valor y recibimos otro. El error está en la línea 24 (Assert).

Garantía de calidad del software con TDD (Test Driven Development) 6

Implementemos lo mínimo, esto hará que nuestra prueba pase.

Garantía de calidad del software con TDD (Test Driven Development) 7

Simplemente estamos devolviendo el valor de la compra pasado como la cantidad después del descuento. Ejecuta las pruebas y deben ponerse verdes.

Garantía de calidad del software con TDD (Test Driven Development) 8

¿Es necesario hacer Refactoring? Por el momento no. Podemos pasar al siguiente criterio de aceptación.

Criterios de Aceptación 02

Dado que el cliente realizó una compra de BRL 500,00

Cuándo cerrar la compra

Entonces recibe un 10% de descuento Y el precio final de compra pasa a ser BRL 450,00.

Observa que ahora ya debemos tener una condición. Si la compra es de BRL 500,00, entonces el método de cálculo debería arrojar BRL 450,00. Creemos la prueba:

Teste do segundo critério de aceitação.

Ten en cuenta que conservo todas las pruebas que he creado. Y que son más o menos un Copiar y Pegar el uno del otro. Al ejecutar las pruebas, obtendrás 1 verde de la prueba anterior y 1 rojo de la prueba que no está pasando y todo se volverá rojo.

Garantía de calidad del software con TDD (Test Driven Development) 9

Implementemos una vez más lo mínimo para que la cosa funcione.

Garantía de calidad del software con TDD (Test Driven Development) 10

Ejecuta las pruebas. Notaremos que todo está de color verde.

1, 2, N

¿Qué sucede si el precio de compra es de BRL 600,00? ¿Pasará? Crea una prueba para esto.

Segundo teste verificando o critério de aceitação 02 com um valor de compra de $600,00

Ejecuta las pruebas. ¿No pasó? ¿Por qué?

Garantía de calidad del software con TDD (Test Driven Development) 11

Usemos el modelo estándar 1, 2, N. Esto significa que modificaremos el código lo suficientemente como para que la prueba pase de la primera vez. Lo preciso para pasar la segunda vez. A partir de ahí, creamos un patrón y podemos dar una solución más concreta para todos los casos.

Entonces, implementemos lo suficiente para que esta prueba pase y mantengamos las demás en funcionamiento.

Garantía de calidad del software con TDD (Test Driven Development) 12

Ejecuta las pruebas y verás que todo estará de color verde.

Ahora bien, ¿si el precio de compra es de BRL739,50 ? Ya tenemos un estándar. Es hora de poner nuestra solución para cumplir con todos los N casos posibles. Creemos la prueba primero.

Garantía de calidad del software con TDD (Test Driven Development) 13

Ejecuta las pruebas. Este último no pasará. Cambiemos la clase empresarial, pero esta vez tratando de atender todos los casos.

Garantía de calidad del software con TDD (Test Driven Development) 14

Ejecuta las pruebas y verás que tendremos éxito en los 4.

Refactoring

¡Dios! Este código es feo. Ahora que hemos creado nuestro protector de pantalla y nuestro código está pasando por todas las pruebas, podemos refactorizarlo. Usemos algunas prácticas de Clean Code (Código Limpio) y deshagámonos de los números mágicos y espacios innecesarios.

Garantía de calidad del software con TDD (Test Driven Development) 15

Siempre ejecuta las pruebas después de refactoring para ver si todo sigue funcionando.

Garantía de calidad del software con TDD (Test Driven Development) 16

Resumen del artículo

En este artículo hemos hablado sobre Test Driven Development (TDD). Te hemos enseñado el ciclo Red, Green, Refactor que debes utilizar a lo largo de todo el desarrollo. La estructura de un buen código de prueba con Arrange, Act y Assert. Por qué deberías caminar a pasos de bebé (baby steps), la estrategia de creación de código comercial 1, 2, N. También hemos desmitificado la idea de que la refactorización es algo malo. De hecho, se requiere cuando estamos mejorando la calidad de nuestro código fuente.

Si has llegado hasta aquí, ya conoces los conceptos básicos de TDD. Puedes dejar de leer y empezar a practicar. A continuación, pondré solo dos situaciones que suelen ocurrir y sería interesante que supieras cómo afrontarlas.

¿Quieres saber más sobre este tema?

El código de este artículo está disponible en GitHub en el enlace https://github.com/avelinoferreiragf/K21-CSD

Lee también los libros citados en este artículo:

Epílogo Parte I: ¡Gran rebaja!

¡Rebaja inédita! La promoción tuvo tanto éxito que ahora se otorga un 20% de descuento en compras superiores a BRL 1.000,00.

El Product Owner creó la historia de usuario: Yo, como comprador, quiero recibir un 20% de descuento en compras superiores a BRL 1.000,00 ya que tengo que comprar muchos regalos y quiero seguir ahorrando mi paga extra.

Criterios de Aceptación 03.

Dado que el cliente realizó una compra de BRL 1.000,00

Cuándo cerrar la compra

Entonces recibe un 20% de descuento Y el precio final de compra pasa a ser de BRL 800,00.

¿Qué hacemos primero? …. Eso es, la prueba que valida esta condición.

Garantía de calidad del software con TDD (Test Driven Development) 17

Ejecuta las pruebas y obtendremos un error que indica que no se cumplieron los criterios de aceptación.

Implementemos lo mínimo para que siga funcionando.

Garantía de calidad del software con TDD (Test Driven Development) 18

Crea tantas pruebas como consideres relevantes. Principalmente probando valores límite como BRL 999.99. Refactoriza cuando hayas creado tu protector de pantalla y todo esté de color verde.

Garantía de calidad del software con TDD (Test Driven Development) 19

Epílogo Parte II: Programador descuidado.

El equipo de marketing quiere incentivar la compra por impulso y hacer un experimento dando un 5% de descuento para compras inferiores a BRL 500,00. El PO creó entonces una nueva historia de usuario: Yo, como dependiente, quiero fomentar la compra por impulso otorgando un descuento del 5 % que aumente mis ingresos en un 20%. La OP junto con el equipo establecieron los siguientes criterios de aceptación:

Criterios de Aceptación 04

Dado que el cliente realizó una compra de BRL 499,99

Cuándo cerrar la compra

Entonces recibes un 5% de descuento Y el precio de compra final pasa a ser de BRL 474,99.

El problema fue que un nuevo programador se unió al equipo y no tomó la formación de Pruebas Automatizadas con Prácticas Ágiles y tampoco la de Certified Scrum Developer. Mucho menos leyó este buen artículo. Lo primero que hizo fue modificar el código comercial.

Garantía de calidad del software con TDD (Test Driven Development) 20

¿Qué pasará entonces? Si usas un servidor de integración continua como Jenkins, ejecutará automáticamente todas las pruebas cada vez que detecte cambios en su repositorio de control de versiones (Subversion o Git, por ejemplo). Y acusará un error, porque se cambió una regla comercial y las pruebas no.

Garantía de calidad del software con TDD (Test Driven Development) 21

Compartilhe

Escrito por

Avelino Ferreira Gomes Filho

Agile Expert e Trainer na K21


Avelino é formado e mestre em Ciência da Computação. Teve uma longa trajetória na T.I. começando como programador e chegando à gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis desde 2008. A partir de 2015 se dedicou a auxiliar outras empresas a adotar tais métodos. Atualmente é Agile Coach e Trainer na Knowledge 21.
Esta publicación tiene la licencia Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artículos relacionados

La Analogía Incorrecta para el Desarrollo de Software
30/06/22
< 1 minutos de leitura

    ¿Quieres recibir nuestro contenido?

    Escribe tu nombre y correo electrónico para que te informemos todo lo que sucede por aquí.