Skip navigation.
Home Home

Más pruebas pueden llegar a provocar peor calidad

Pruebas
Pruebas

Aunque parezca una afirmación absurda, el artículo Better Testing, Worse Testing razona sobre las posibles causas que provocaron en distintos casos el que un mayor número de pruebas por parte de los desarrolladores condujo a un mayor número de defectos en el código. Estos casos se explican en un artículo anterior denominado Better Testing, Worse Quality.

Pasado algún tiempo el autor llega a la conclusión de que un aumento de las pruebas de un tipo (en su caso las elaboradas por el desarrollador) pueden ser perjudiciales si conllevan un menor número de pruebas de otro tipo (en su caso pruebas de sistema o funcionales).

Es una interesante lectura. De hecho tras los primeros artículos que leí sobre pruebas en Extreme Programming también entendí que con las pruebas unitarias las pruebas de más alto nivel eran menos importantes. Sólo leyendo mucho más te das cuenta de la maliterpretación. Está claro que los que divulgan (divulgamos) los métodos ágiles tienen (tenemos) que tener cuidado de los malentendidos a los que puede darse lugar.

Escribir código de test no es una actividad mecánica

La verdad es que no entiendo bien el razonamiento... pero comparto la afirmación.

El problema viene cuando se afronta el código de test como una actividad sistemática, mecánica o de segunda categoría. El resultado puede ser una gran cantidad de código de test donde buena parte de mismo no es es muy útil. Y es entonces cuando aparecen los problemas.

Con las pruebas ocurre algo curioso y es que la relación número de pruebas vs beneficio obtenido no es nada lineal. Unas pocas pruebas bien elegidas aportan un gran beneficio y añadiendo más se gana pero cada vez menos, hasta llegar a un punto en el que demasiado código de pruebas (y mal elegido) puede ser contraproducente.

Además las pruebas no sólo tienen un coste de realización sino también de mantenimiento, este último coste es importante tenerlo en cuenta.

Saludos