Hecho Número Uno: Muy pocos desarrolladores (si es que hay alguno...) disfrutan probando lo que han desarrollado (por no hablar de lo que han desarrollado otros): es una tarea poco agradecida, rutinaria y repetitiva. Hecho Número Dos: Los desarrolladores de software están capacitados para crear programas que se ocupen automáticamente de tareas repetitivas, rutinarias y poco agradecidas.
Parece que de aquí se puede sacar inmediatamente una conclusión clara: ¿por qué no automatizar la realización de las pruebas del software?. Seguramente eso es lo que pensaron los creadores de JUnit cuando se decidieron a desarrollar un framework para facilitar la realización de las llamadas Pruebas Unitarias. El concepto parece que tuvo éxito y hoy JUnit está acompañado en el mundo cel código abierto por productos similares que permiten automatizar las pruebas en diversos entornos que no sean Java: NUtit (.NET), CppUnit (C++), pyUnit (Python)... en lo que se conoce colectivamente como familia xUnit
Sobre el papel, el uso de estos frameworks parece estar lleno de ventajas. Sin embargo, no son pocos los inconvenientes que aparecen al intentar adoptar su uso. Uno de los primeros, si no el principal, consiste en convencer a la gente, tanto a la que va a usarla como a los que toman las decisiones y auditan el tiempo dedicado al desarrollo. Es difícil convencer a la gente de que dedicar tiempo a escribir código que prueba otro código no es una pérdida de tiempo, sino una inversión. Aún estando convencido, es necesario disciplinarse para dedicarle el tiempo necesario (algo de lo que pocos proyectos suelen disponer en abundancia). De hecho, he visto rechazar ofertas de proveedores que incluían una partida dedicada al desarrollo de las baterías de pruebas, para quedarse con la misma oferta sin las pruebas (un poco más barata, claro). Y ello a pesar de que casi todos conocemos y hemos padecido el caso de proyectos grandes en los que, cada vez que se modifica algo, hay que probar (manualmente) toda la funcionalidad de nuevo porque puede haberse "roto" algo. En definitiva, una pesadilla de mantenimiento que podría haberse paliado con una política de pruebas automáticas adecuada.
Por otro lado, el uso de estas herramientas no siempre es sencillo. La instalación y uso en Java + Eclipse es casi trivial. Sin embargo, no me he animado a probar CppUnit (entre otras cosas porque empleo eMbedded Visual C++, no un Visual Studio más standard) porque no he visto claras inicialmente las instrucciones de instalación (igual leyéndolas con más detenimiento...). No conozco el caso de NUnit (aunque apostaría porque no será complejo de usar), y recuerdo haber trasteado un poco hace años con un VBUnit para Visual Basic que se integraba bastante bien con su IDE. Finalmente, no he probado pyUnit, pero porque Python lo utilizo básicamente para scripts más o menos sencillos y prototipos rápidos: no le veo mucho sentido a integrar las pruebas en estos casos.
Una vez resuelta la instalación y manejo del framework adecuado al lenguaje escogido, viene la gran duda: ¿qué y cómo probar?. Sin ni siquiera entrar en lo verdaderamente problemático (accesos a bases de datos, interfaces de usuario...), la mayoría de los ejemplos que se encuentran en la literatura del tema son demasiado triviales y no ayudan a ver como puede aplicarse todo esto en un proyecto real. A su favor hay que decir que la editorial Pragmatic Bookshelf tiene un par de títulos (Pragmatic Unit Testing in Java with JUnit y Pragmatic Unit Testing in C# with NUnit) que intentan dar un enfoque práctico a la automatización de las pruebas. Aún así (al menos el de Java y JUnit), se quedan cortos en lo que a ejemplos reales se refiere, aunque presentan una serie de prácticas y guías bastante útiles.
En conclusión, hoy por hoy es un escollo el pretender automatizar las pruebas en mi entorno de desarrollo. Entiendo que es algo necesario, sino imprescindible (sobre todo en proyectos de buen tamaño), pero no dispongo del tiempo necesario para experimentar y probar el xUnit correspondiente en un proyecto real. Eso sí, espero poder hacerlo algún día (y ahora mismo se ven posibilidades en el horizonte...).
No hay comentarios:
Publicar un comentario