top of page

Test Smells: Ronda 2


Emoji de caca mostrado por persona
Esos tests no huelen muy bien...

Cómo andan? Espero se encuentren estupendamente bien! En este post quería retomar un tema que toqué una vez ya, y es sobre "smells" en testing, cómo identificarlos y qué hacer al respecto. Seguramente no llegue a cubrir TODOS los que faltan en este post, así que esperen más de esta olorosa saga. Una última aclaración: Dado que durante mi carrera mayormente programé con Java y JavaScript, van a notar que la mayoría de los ejemplos van por ese lado.


Convención para los nombres de clases, tests, métodos, variables, etc.


  • Conflicto de Identidad: El nombre del test no tiene nada que ver con lo que testea. En este caso lo mejor es levantar la mano, decir que ese test está informando algo incorrecto y refactorizar ese código para que refleje lo que dice el nombre del test o bien cambiar el nombre del test para que refleje lo que su implementación hace.

  • Tests anónimos: Este va un paso más allá y ya no solo el nombre está equivocado, sino que no nos dice qué es lo que está testeando. Puede ser un nombre muy vago, algo muy general que no informe lo que el test está haciendo. En este caso, y considerando que la implementación sea correcta, basta con ponerle el nombre que corresponde.

  • Tests sin acciones: Un test tiene que tener una acción. Qué está intentando hacer para ver si funciona? Si el test dice "El botón de Login" nada más, algo no cuadra...

Problemas de estructura


  • Muchos tests para una misma cosa: Clara señal de que faltó parametrizar el caso de pruebas. Si tuviste que escribir exactamente las mismas líneas de código para cubrir otra data, deberías parametrizar el test para que itere con distintos sets de datos.

  • El dependiente: Un test que solo va a correr bien si un test previo se ejecutó con éxito. Los tests tienen que ser SIEMPRE independientes. Para setear data podemos usar otras técnicas, como vemos en los cursos (dB seeding, API requests, etc).

  • A limpiar el lio: Esto pasa cuando es necesario borrar algún recurso importante (como una tabla en una dB) para cada test. Generalmente otro síntoma de no tener los tests independientes como vimos antes o cuando la implementación de un test es muy larga.