A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

El software nunca está realmente terminado. Incluso después de que un programa se lanza, los desarrolladores deben volver constantemente a él para corregir errores, añadir nuevas funciones y adaptarse a las necesidades cambiantes. Este trabajo continuo se llama mantenimiento, y a menudo requiere más esfuerzo que la creación inicial del software en sí. Para que este trabajo sea manejable, los programadores a veces dejan notas en su código, admitiendo que una sección particular es desordenada, temporal o no es del todo correcta. Pueden escribir un comentario que diga: "Esto es un parche" o "Corregir esto después". En el mundo de la ingeniería de software, estas confesiones honestas se conocen como deuda técnica admitida. Son como un desarrollador diciendo: "Sé que esta no es la mejor manera de hacerlo, pero necesitábamos terminarlo ahora". Aunque los investigadores han estudiado durante mucho tiempo estas notas en el código principal que ejecuta un programa, han ignorado en gran medida las notas encontradas en el código utilizado para probar ese programa. Este es un descuido significativo, porque si las pruebas mismas son defectuosas o están mal escritas, todo el sistema de software se vuelve poco fiable.

Un equipo de investigadores de la Universidad de Manitoba se propuso comprender esta capa oculta de deuda. Se centraron en un tipo específico de software escrito en Java, un lenguaje ampliamente utilizado para construir aplicaciones complejas. Para obtener una imagen clara, recopilaron una colección masiva de más de un millón de comentarios de mil proyectos diferentes de código abierto. De este vasto conjunto, seleccionaron al azar cincuenta mil comentarios para examinarlos a mano. Esta revisión manual fue un trabajo minucioso, que requería que los investigadores leyeran cada nota y decidieran si representaba una admisión genuina de un problema o simplemente una explicación estándar. Tras filtrar los comentarios que no eran relevantes o que provenían de un solo proyecto que sesgara los datos, identificaron 615 comentarios que eran ejemplos reales de deuda técnica en el código de prueba.

Los investigadores descubrieron que la naturaleza de estas deudas en el código de prueba es bastante diferente de la que se encuentra en el código de la aplicación principal. Clasificaron los 615 casos en once categorías distintas. Algunas de ellas eran familiares, como notas sobre un mal diseño o falta de documentación. Sin embargo, cuatro categorías eran completamente nuevas y específicas del mundo de las pruebas. Estas incluían "pruebas limitadas", donde un desarrollador admite que la prueba solo comprueba una porción diminuta y no representativa del problema; "saltar pruebas", donde una prueba se desactiva explícitamente porque no puede ejecutarse en el entorno actual; "en espera", donde una prueba espera a que una herramienta o servicio externo esté disponible; e "incertidumbre", donde el desarrollador no está seguro de si la prueba es siquiera correcta. Esta taxonomía reveló que el código de prueba conlleva sus propias cargas únicas, a menudo relacionadas con los desafíos específicos de validar el comportamiento del software en lugar de construirlo.

Habiendo mapeado cómo se ven estas deudas, el equipo se planteó una segunda pregunta, más práctica: ¿Pueden las computadoras encontrarlas automáticamente? Probaron siete herramientas existentes diseñadas para detectar estas notas en el código fuente regular. También probaron una gama de modelos de inteligencia artificial, incluyendo tanto modelos de código abierto como potentes sistemas propietarios de grandes empresas tecnológicas. Los resultados fueron sorprendentes. Las herramientas existentes, que dependen de la búsqueda de palabras clave específicas como "TODO" o "FIXME", tuvieron el mejor desempeño entre los métodos tradicionales, pero aun así pasaron por alto más de un tercio de las deudas reales. Eran buenas para ser correctas cuando encontraban algo, pero fallaban al encontrar muchos de los problemas reales.

Los modelos de inteligencia artificial tuvieron un desempeño incluso peor en aspectos distintos. Los modelos de código abierto tuvieron dificultades para encontrar las deudas en absoluto, fallando a menudo en el reconocimiento a menos que las notas contuvieran palabras clave muy obvias. Cuando encontraban algo, con frecuencia se equivocaban. Los modelos propietarios, que generalmente se consideran más avanzados, mostraron el problema opuesto. Encontraban casi todas las deudas, pero también señalaban cientos de comentarios inofensivos como problemas. Eran tan ansiosos por encontrar problemas que confundían explicaciones rutinarias con admisiones de fallo. Al final, ni las herramientas tradicionales ni los sistemas de IA más avanzados podían detectar estas deudas en el código de prueba de manera fiable.

El estudio concluye que la forma en que los desarrolladores escriben sobre los problemas en el código de prueba es fundamentalmente diferente a cómo escriben sobre los problemas en el código principal. Las notas en los archivos de prueba suelen utilizar un lenguaje específico del proceso de prueba, como mencionar que una prueba está "deshabilitada" o "saltada", algo que las herramientas estándar y los modelos de IA no reconocen como un signo de deuda. Los investigadores descubrieron que los métodos actuales aún no están preparados para manejar esta complejidad. Han creado un nuevo conjunto de datos y un mapa detallado de estos tipos de deuda para ayudar a futuros investigadores a construir mejores herramientas de detección. Hasta entonces, la tarea de encontrar y solucionar estos fallos ocultos en el código de prueba sigue siendo un trabajo que requiere atención humana.