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.

  • Prolijidad ante todo: Están codeando en Java? Péguense una leída a las convenciones para escribir en ese lenguaje. Espacios, mayúsculas, minúsculas...etc. Yo lo aprendí bien bien cuando me tocó trabajar con la que ahora es una gran amiga (de USA) que en los Pull Requests me marcaba TODOS los espacios y detalles de este tipo.


Problemas en el código


  • Nombres falopa: Cuando te encontrás con variables que se llaman "String1" o métodos "codeForTest" te dan ganas de revolear una silla por la ventana en la oficina. Qué hace el método? De qué es la variable? Hay que poner un nombre coherente para que cualquiera que lo lea sea de qué se está hablando.

  • Infierno de condicionales: Cuando un solo test trata de hacer demasiadas cosas de forma "inteligente" y para eso recurre a una plétora de if/elses y switch/cases de manera tal que seguir el flujo de lo que hace te hace doler la cabeza. Mantengan las implementaciones sencillas gente! A veces, en el afán de hacer algo épico terminamos creando un monstruo infumable de mantener y usar para el resto (y nosotros).

  • Infierno de expresiones regulares: Similar al caso anterior. Si, está buenísimo que sepas usar expresiones regulares infinitas para hacer algo en una sola línea, pero... da que lo hagas? Generalmente la respuesta es no porque lleva a una complejidad bastante molesta de leer. Usen las expresiones regulares con sabiduría (o en algún challenge entretenido de código).


Problemas fundamentales de no saber técnicas de testing.

  • Falta de técnica: Sabían que existen muchas técnicas en testing para ayudarnos a diagramar casos de prueba? Cuando esto no se sabe, se suelen cometer omisiones (no testeamos el valor 0...oops, esto tenía BOCHA de bugs) en la creación de los casos de prueba en la forma de testear muy literalmente lo que dice el criterio de aceptación sin mucho cerebro metido en ese proceso. En el curso de Introducción al Testing de Software van a aprender justamente esas técnicas! Les sorprendería la de testers seniors que he conocido a lo largo de los años que no sabían usarlas...

  • Test Data con fecha de caducidad: Cuando los tests son creados con test data asociada que va a empezar a fallar en el futuro. Por ejemplo "seleccionar la fecha de hoy" con un resultado esperado explícito de "la fecha debería ser 19 de Septiembre 2022". Esto es especialmente dañino en test data usada para automation.

  • Test Cases al infinito y más allá: Cuando nos encontramos con test cases que se desvían del criterio de aceptación que tenemos en la historia que testean y terminan haciendo prácticamente una pequeña regresión ahí mismo. Esto genera confusión a la hora de encontrar defectos ya que se asocian a una historia en la que se desarrolló algo que nada que ver. Hay un lugar y momento para esos defectos y este no es...

  • El tester optimista: Cuando se crean tests solamente para los casos positivos y no se crea nada para probar los casos negativos. Si sos tester y hacés esto... pensá seriamente lo que estás haciendo!


Conclusión


Y acá terminamos con otra tanda de smells en testing. Tanto para Automation como para Testing Manual. Estoy seguro que siguen habiendo más que ahora no me acuerdo, así que los invito a leer el post anterior, este y sumar los que ustedes piensen que son Test Smells a este post!

54 visualizaciones0 comentarios

Entradas Recientes

Ver todo