Test Behaviors, Not Methods! Detecting Tests Obsessed by Methods
Este artículo propone un nuevo "test smell" llamado "Test Obsessed by Method", el cual identifica pruebas que cubren múltiples rutas de ejecución de un único método de producción, y valida su detección mediante un estudio empírico en la Biblioteca Estándar de Python, demostrando que tales pruebas a menudo verifican múltiples comportamientos y pueden ser refactorizadas en unidades más enfocadas.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que eres un chef preparando un menú de degustación para un crítico gastronómico. La regla de oro de la buena cocina es: sirve un sabor distinto por plato. Si sirves un solo plato que contiene un filete, una rebanada de pastel y una bola de helado todo mezclado, el crítico se confundirá. No podrá saber si el filete está poco hecho, si el pastel es demasiado dulce o si el helado se está derritiendo. Si algo sale mal, no sabrá a qué parte de la comida culpar.
En el mundo del software, los "platos" son pruebas (tests), y los "sabores" son comportamientos (lo que el software debe hacer).
Este artículo, titulado "¡Pruebas de Comportamientos, no de Métodos!", sostiene que muchas pruebas de software se están sirviendo actualmente como ese plato mezclado y desordenado. Los autores, Andre Hora y Andy Zaidman, introducen una nueva forma de detectar estas pruebas confusas, lo que ellos llaman "Pruebas Obsesionadas por Métodos".
Aquí tienes el desglose de su descubrimiento utilizando analogías sencillas:
1. La forma antigua: Contar los ingredientes
Anteriormente, los expertos intentaban encontrar estas pruebas desordenadas simplemente contando cuántas veces una prueba "tocaba" el código. Pensaban: "Si una prueba llama al código de producción 3 o más veces, probablemente esté haciendo demasiado".
Los autores llaman a este olor (smell) "Prueba Ansiosa" (Eager Test). Sin embargo, descubrieron que este método es como juzgar una comida solo por contar cuántas cucharas se usaron. Es inexacto. Una prueba puede llamar a una función muchas veces solo para preparar la escena, sin estar realmente probando diferentes sabores. Es una forma torpe de encontrar el problema.
2. La nueva idea: Ver la película (Análisis en tiempo de ejecución)
En lugar de solo contar cucharadas, los autores sugieren ver la película de la prueba mientras se reproduce. Proponen una nueva regla: Si una sola prueba obliga a una pieza de código a tomar múltiples "caminos" (rutas) diferentes para llegar a la meta, esa prueba está "obsesionada".
Piensa en un método de producción (una pieza de código) como un laberinto.
- Buena Prueba: Envías a un explorador al laberinto para comprobar si la puerta izquierda funciona. Luego envías a un segundo explorador para comprobar si la puerta derecha funciona. Claro y enfocado.
- Prueba Obsesionada: Envías a un explorador que pasa por la puerta izquierda, luego retrocede, pasa por la puerta derecha y luego intenta el túnel secreto, todo en un mismo movimiento.
Los autores llaman a esto "Prueba Obsesionada por Método". La prueba es "codiciosa" porque intenta cubrir todos los caminos posibles de un solo laberinto de una sola vez, en lugar de dividir el trabajo.
3. El experimento: Revisando la librería de Python
Para ver si esta "obsesión" es un problema real, los autores realizaron una búsqueda del tesoro a través de la Librería Estándar de Python (una enorme colección de código preescrito utilizado por millones de desarrolladores).
Examinaron 2.054 pruebas. Esto fue lo que encontraron:
- La búsqueda: Encontraron 44 pruebas que estaban "obsesionadas". Estas pruebas intentaban comprobar múltiples resultados distintos de una sola función de una sola vez.
- La dispersión: Estas pruebas desordenadas se encontraron en 11 de las 12 librerías diferentes que revisaron. No es un error raro; es un hábito común.
- La solución: En promedio, cada una de estas 44 pruebas desordenadas estaba en realidad intentando hacer dos trabajos diferentes. Si las dividieran, esas 44 pruebas podrían convertirse en 118 pruebas limpias y enfocadas.
- El momento "¡Ajá!": En aproximadamente el 23% de estas pruebas desordenadas, los programadores habían escrito comentarios admitiendo: "¡Oye, estamos probando dos cosas diferentes aquí!". Sabían que era desordenado, pero lo hicieron de todos modos.
4. ¿Por qué es esto importante?
Los autores argumentan que cuando una prueba intenta cubrir demasiados caminos a la vez:
- Es difícil de entender: Como ese plato mezclado, no puedes saber qué sabor estás probando.
- Es frágil: Si cambias el código de la "puerta izquierda", podrías romper accidentalmente la prueba de la "puerta derecha", aunque no estén relacionadas.
- Es difícil de arreglar: Cuando una prueba falla, no sabes qué comportamiento específico se rompió.
La conclusión
El artículo no pretende resolver todos los problemas de las pruebas. En cambio, ofrece una herramienta más aguda (usando el análisis en tiempo de ejecución en lugar de solo contar) para detectar pruebas que intentan hacer demasiado con una sola pieza de código.
Sugieren que si una prueba obliga a una función a tomar múltiples caminos diferentes, debería dividirse. Así como un chef debe servir el filete, el pastel y el helado en platos separados, un desarrollador debe escribir pruebas separadas para cada comportamiento distinto.
En resumen: No seas codicioso con tus pruebas. Prueba un comportamiento, un camino, un sabor a la vez.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.