Las cosas por sus nombre

#testing #beginners #programming

Ayer fue la #pulpoCon22 que se ha consolidado como como uno de mis eventos favoritos y que creo que dará mucho de que hablar en el futuro.

Entre otras cosas tuve la oportunidad de desvirtualizar al gran @talkingbit1 que me confesó que el secreto del éxito es escribir algo todos los días y pude asistir a una charla sobre testing de @nuria_codes donde entendí que dijo que los nombres de los tests no importan y que dedicamos demasiado esfuerzo y tiempo a ponerle apodos a las cosas en lugar de reflexionar sobre sus características.

En parte estoy de acuerdo y me gustaría recomendar leer las reflexiones del gran Richard Feynman donde habla entre otras cosas, sobre la diferencia entre nombrar vs conocer.

Es cierto que para hablar con alguien de forma efectiva y eficiente es recomendable disponer de un lenguaje común, pero es importante recordar que al menos en cuanto a testing los nombres son lo de menos. Lo importante es conocer las características, comportamiento y ventajas e inconvenientes de cada tipo de test independientemente del nombre que le demos.

En particular a la hora de hablar de un test me gusta acotar las siguientes características:

Sensibilidad: Probabilidad de fallar si existe un error en el código.
Especificidad: Probabilidad de dar por válido un comportamiento correcto del código.
Fragilidad: Probabilidad de que un test de falsos positivos. Se compone a su vez de:
- Estabilidad: Probabilidad de que un test de el mismo resultado en diferentes ejecuciones.
- Flexibilidad: Tolerancia de un test a cambios en la implementación que no afectan al comportamiento.
Precisión: Mide cómo de complicado es identificar la fuente del error si el test falla.
Mantenibilidad: Mide cómo de complicado es actualizar o modificar el código del test.
Velocidad: Mide cuánto tiempo tarda el test en ejecutarse.
Profundidad : Indica el número de componentes y dependencias que se ejecutan en el test.

Con estas características encima de la mesa creo que uno de los debates más frecuentes es la discusión entre qué es un test unitario y qué es un test de integración. Algunos consideran que un test unitario prueba sólo una unidad (profundidad cero) y otros como Fowler introducen el concepto de test unitarios sociables para poder denominar tests unitarios a tests con profunidad N.

Este dogmatismo en cuanto a nombres y "buenas prácticas" hace que algunos se obsesionen con cumplir la máxima de "la pirámide de tests dice que tenemos que tener muchos test unitarios" y llenan la base de código de tests que no sirven absolutamente para nada mientras que jamás probarán un caso de uso completo porque "esos tests son frágiles y es malo que un test sea frágil"

En resumen, aunque llamar a las cosas por su nombre es una buena idea para tener una conversación fluida por desgracia todavía no tenemos unos nombres establecidos en la industria.

Mientras eso no ocurra, si queremos evitar situaciones donde se imponga el fanatismo y el dogmatismo, lo mejor sería que antes de cada discusión nos aseguráramos de que todos los participantes conocen las características de los tipos de tests de los que vamos a hablar para poder centrar la conversación en las ventajas y riesgos que asumimos con cada uno de ellos y poder usar la cabeza para determinar cuál es la mejor estrategia de testing para nuestro caso particular en lugar de seguir recetas y soluciones milagrosas totalmente a ciegas.

Top comments (4)

Juan Vega • Sep 5 '22

Lo que yo suelo hacer es hablar con el equipo para asegurarnos que estamos todos en la misma página en cuentao a que significan las diferentes etiquetas. Tambien suelo cuestionar la piramide y pensar si según el contexto del código a lo que hemos llamado "integración" nos beneficia más aunque sea más fragil o más lento.