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.