Diseño ágil con TDD

12.2. Antipatrones

James Carr recopiló una lista de antipatrones ayudado por la comunidad TDD que traduje en mi blog y que ahora añado a esta sección.

Los nombres que les pusieron tienen un carácter cómico y no son en absoluto oficiales pero su contenido dice mucho. Algunos de ellos ya están recogidos en los errores comentados arriba.

12.2.1. El Mentiroso

Un test completo que cumple todas sus afirmaciones (asserts) y parece ser válido pero que cuando se inspecciona más de cerca, muestra que realmente no está probando su cometido en absoluto.

12.2.2. Setup Excesivo

Es un test que requiere un montón de trabajo para ser configurado. A veces se usan varios cientos de líneas de código para configurar el entorno de dicho test, con varios objetos involucrados, lo cual nos impide saber qué es lo que se está probando debido a tanto "ruido".

12.2.3. El Gigante

Aunque prueba correctamente el objeto en cuestión, puede contener miles de líneas y probar muchísimos casos de uso. Esto puede ser un indicador de que el sistema que estamos probando es un Objeto Todopoderoso.

12.2.4. El Imitador

A veces, usar mocks puede estar bien y ser práctico pero otras, el desarrollador se puede perder imitando los objetos colaboradores. En este caso un test contiene tantos mocks, stubs y/o falsificaciones, que el SUT ni siquiera se está probando. En su lugar estamos probándolo que los mocks están devolviendo.

12.2.5. El Inspector

Viola la encapsulación en un intento de conseguir el 100 % de cobertura de código y por ello sabe tanto del objeto a prueba que, cualquier intento de refactorizarlo, rompe el test.

12.2.6. Sobras Abundantes

Es el caso en que un test crea datos que se guardan en algún lugar y otro test los reutiliza para sus propios fines. Si el generador de los datos se ejecuta después, o no se llega a ejecutar, el test que usa esos datos falla por completo.

12.2.7. El Héroe Local

Depende del entorno de desarrollo específico en que fue escrito para poder ejecutarse. El resultado es que el test pasa en dicho entorno pero falla en cualquier otro sitio. Un ejemplo típico es poner rutas que son específicas de una persona, como una referencia a un fichero en su escritorio.

12.2.8. El Cotilla Quisquilloso

Compara la salida completa de la función que se prueba, cuando en realidad sólo está interesado en pequeñas partes de ella. Esto se traduce en que el test tiene que ser continuamente mantenido a pesar de que los cambios sean insignificantes. Este es endémico de los tests de aplicaciones web. Ejemplo, comparar todo un HTML de salida cuando solo se necesita saber si el title es correcto.

12.2.9. El Cazador Secreto

A primera vista parece no estar haciendo ninguna prueba por falta de afirmaciones (asserts). El test está en verdad confiando en que se lanzará una excepción en caso de que ocurra algún accidente desafortunado y que el framework de tests la capturará reportando el fracaso.

12.2.10. El Escaqueado

Un test que hace muchas pruebas sobre efectos colaterales (presumiblemente fáciles de hacer) pero que nunca prueba el auténtico comportamiento deseado. A veces puede encontrarse en tests de acceso a base de datos, donde el método a prueba se llama, después el test selecciona datos de la base de datos y hace afirmaciones sobre el resultado. En lugar de comprobar que el método hace lo que debe, se está comprobando que dicho método no alteró ciertos datos o, lo que es lo mismo, que no causó daños.

12.2.11. El Bocazas

Un test o batería de tests que llenan la consola con mensajes de diagnóstico, de log, de depuración, y demás forraje, incluso cuando los tests pasan. A veces, durante la creación de un test, es necesario mostrar salida por pantalla, y lo que ocurre en este caso es que, cuando se termina, se deja ahí aunque ya no haga falta, en lugar de limpiarlo.

12.2.12. El Cazador Hambriento

Captura excepciones y no tiene en cuenta sus trazas, a veces reemplazándolas con un mensaje menos informativo, pero otras incluso registrando el suceso en un log y dejando el test pasar.

12.2.13. El Secuenciador

Un test unitario que depende de que aparezcan, en el mismo orden, elementos de una lista sin ordenar.

12.2.14. Dependencia Oculta

Un primo hermano del Héroe Local, un test que requiere que existan ciertos datos en alguna parte antes de correr. Si los datos no se rellenaron, el test falla sin dejar apenas explicación, forzando al desarrollador a indagar por acres de código para encontrar qué datos se suponía que debía haber.

12.2.15. El Enumerador

Una batería de tests donde cada test es simplemente un nombre seguido de un número, ej, test1, test2, test3. Esto supone que la misión del test no queda clara y la única forma de averiguarlo es leer todo el test y rezar para que el código sea claro.

12.2.16. El Extraño

Un test que ni siquiera pertenece a la clase de la cual es parte. Está en realidad probando otro objeto (X), muy probablemente usado por el que se está probando en la clase actual (objeto Y), pero saltándosela interacción que hay entre ambos, donde el objecto X debía funcionar en base a la salida de Y, y no directamente. También conocido como La Distancia Relativa.

12.2.17. El Evangelista de los Sistemas Operativos

Confía en que un sistema operativo específico se está usando para ejecutarse. Un buen ejemplo sería un test que usa la secuencia de nueva línea de Windows en la afirmación (assert), rompiéndose cuando corre bajo Linux.

12.2.18. El que Siempre Funciona

Se escribió para pasar en lugar de para fallar primero. Como desafortunado efecto colateral, sucede que el test siempre funciona, aunque debiese fallar.

12.2.19. El Libre Albedrío

En lugar de escribir un nuevo test unitario para probar una nueva funcionalidad, se añade una nueva afirmación (assert) dentro de un test existente.

12.2.20. El Unico

Una combinación de varios antipatrones, particularmente El Libre Albedrío y El Gigante. Es un sólo test unitario que contiene el conjunto entero de pruebas de toda la funcionalidad que tiene un objeto. Una indicación común de eso es que el test tiene el mismo nombre que su clase y contiene múltiples líneas de setup y afirmaciones.

12.2.21. El Macho Chillón

Debido a recursos compartidos puede ver los datos resultantes de otro test y puede hacerlo fallar incluso aunque el sistema a prueba sea perfectamente válido. Esto se ha visto comúnmente en fitnesse, donde el uso de variables de clase estáticas, usadas para guardar colecciones, no se limpiaban adecuadamente después de la ejecución, a menudo repercutiendo de manera inesperada en otros tests. También conocido como El huésped no invitado.

12.2.22. El Excavador Lento

Un test que se ejecuta de una forma increíblemente lenta. Cuando los desarrolladores lo lanzan, les da tiempo a ir al servicio,tomar café, o peor, dejarlo corriendo y marcharse a casa al terminar el día.

12.2.23. Notas finales

Por último yo añadiría como antipatrón el hecho de ponerle comentarios a un test. Para mí, si un test necesita comentarios, es que no está bien escrito.

No se tome a pecho cada uno de los patrones ni los errores. Como en tantas otras áreas, las reglas tienen sus excepciones. El objetivo es que le sirvan para identificar "malos olores" en su práctica conTDD.


Copyright (c) 2010-2013 Carlos Ble. La copia y redistribución de esta página se permite bajo los términos de la licencia Creative Commons Atribución SinDerivadas 3.0 Unported siempre que se conserve esta nota de copyright.