La importancia sobre las Pruebas Unitarias

Cada vez desarrollamos Software más y más complejo, y esto produce que los plazos de entrega de nuestro producto a veces se eternicen o que nunca se cumplan. Por eso es muy importante que tengamos un buen proceso para depurar nuestras aplicaciones sin causar un gran trauma ni un gran coste al equipo de desarrollo. Mediante pruebas unitarias, verificamos que cada módulo funcione correctamente por separado, luego con las pruebas de integración probamos que la integración de los módulos sea correcta. La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto. Muchos de los lenguajes de programación, proveen Unit testing como Dunit (para delphi) Junit (para Java) Nunit (para .Net), etc. Una de la técnicas más importantes para conseguir beneficios en nuestras pruebas y mejorar la calidad de nuestro Software, es aplicando (TDD) Test-Driven Development (Desarrollo guiado por pruebas).

Aplicar el TDD no es fácil, ya que requiere un cambio de mentalidad y profundizar bastante en las metodologías ágiles de programación. Este concepto pretende que primero se diseñen los test para nuestro módulo y luego se escriba el módulo. De esta manera el Software tiente a estar mejor diseñado, menos acoplado y más fácilmente mantenible, porque el programador es libre de hacer decisiones de diseño y hacer refactoring en cualquier momento con la seguridad de que el software todavía funciona. El test actúa evitando los bugs, si el desarrollador encuentra un bug, se crear un test que verifique que existe y luego se cambia en el módulo y se vuelve a pasar el test. Con todos estos test, el tiempo de depuración se reduce.

En la siguiente figura podemos ver que cuanto más complejo se vuelve el software y más grande, menos productivo es. Con el crecimiento del tamaño de los proyectos de software, y la complejidad del testeo del código Orientado a Objetos, las aplicaciones tienen millones de combinaciones, estados y caminos. Es imposible para alguien imaginar cada posible estado, incluso cada posible solución.

Numerosos estudios nos muestran que el coste de arreglar un defecto o error en nuestro programa se ve magnificado en función de la fase en que se encuentre. Esto significa que reparar un bug en la fase release puede costar 100 veces más que en la fase de codificación.

Las pruebas unitarias son necesarias (y obligatorias). Idealmente cada desarrollador debería producir un juego de test para validad cada método individual y clase que hayan escrito. Toma bastante tiempo identificar las áreas más problemáticas, escribir los tests, ejecutarlos, monitorizar los resultados, ficheros de seguimiento, etc. Y además, es bastante complicado para nosotros como seres humanos esperar lo "inesperado" (cosas que nunca habíamos imaginado que pasarían). La automatización de las pruebas ayuda mucho y es esencial. Hay que habituarse a utilizarlos ya sea mediante los xUnit o con Mock Objects o Stubs.

• Que nos aporta Agile Development?

En un post anterior sobre las nueve reglas de oro hice una pequeña introducción al desarrollo ágil y la programación extrema. Agile nos entrega una serie de herramientas que permiten mejorar la calidad de nuestro software haciendo que todo el equipo de desarrollo se involucre en esta metodología de trabajo.

El desarrollo Agile, nos introduce muchas herramientas muy interesantes para mejorar nuestra productividad y hacer que nuestro producto salga con una gran calidad y con muy pocos errores. Aquí os dejo un enlace con los axiomas del movimiento ágil: http://www.agileaxioms.com/

1. Scrum
2. Unit testing
3. Test Driven Development
4. Pair programming
5. Sprints/Iterations
6. Writing user stories
7. Continuous integration
8. Bug Tracking

PD: En los enlaces de interés hay una historia muy interesante sobre la complejidad del software de las naves espaciales, y como resuelven todo este tema.

• Enlaces de interés:

http://www.agileadvice.com/
http://haacked.com/archive/2006/10/20/The_Misuse_of_the_Space_Shuttle_Analogy.aspx
http://www.codinghorror.com/blog/archives/000113.html