Uno de los temas que a los programadores nos acostumbra a costar mucho, es la realización de test. Somos «tan buenos» que nos cuesta pensar que podemos equivocarnos, o que nos hemos podido dejar alguna posibilidad por cubrir al momento de programar. Y, no digo que no sea verdad, pero el dejar un test programado, o incluso mejor, el programar un test antes de escribir la clase, solo nos puede traer ventajas; entonces…. ¿Por qué no hacerlo?
La necesidad de escribir test
Existe una forma de programar (TDD) en la que los test de escriben antes que las clases, e incluso, puede que los test los desarrolle un equipo distinto al que programa…y eso esta muy bien, aunque mi intención, al escribir este articulo, es presentaros una forma de conseguir poder dormir tranquilo por las noches, confiando en que tus clases siempre harán lo previsto.
De momento, vamos a ver como enfrentamos un test para aquellas clases que desarrollamos en el articulo correspondiente a SDCA-La creación de los modelos . Este desarrollo se hizo en PHP y ahora vamos a encarar la construcción de test, usando PHPUnit.
El planteamiento que vamos a hacer, es la realización de test unitarios; en este nivel, no tenemos interfaces gráficas, ni nos hemos de preocupar del comportamiento del usuario; cada clase se puede considerar una caja negra con una lista de métodos que reciben unos parámetros, y que han de hacer unas funciones…. así de sencillo
Antes de empezar a revisar el como escribirlo, me gustaria dejar claro alguna cosas que, no por ser obvias, no debemos recalcar.
Porque hacer test
- Te obligas a entender la funcionalidad al detalle:
- Los cambios de entorno dejan de “dar miedo”
- Te ahorras horas y horas de trabajo
- eres capaz de probar decenas, cientos o incluso miles de escenarios, tanto en un entorno controlado como consumiendo los servicios reales…
- Pruebas en unos pocos minutos. Además, no dependerás de la ayuda de compañeros de otras capas del sistema para simular estos escenarios
- Puedes aprovecharlos para extraer automáticamente información gráfica actualizada,
- capturas de pantalla, videos navegando por la aplicación,…
- Puedes hacer pruebas de estabilidad y rendimiento muy completas
- Podemos realizar pruebas diarias, controlando paso a paso nuestro desarrollo
Naturalmente, que para que lo podamos hacer, necesitamos que nuestras clases estén perfectamente desacopladas…pero eso ya cuento con que vosotros programáis asi… !Que menos!
La instalación de PHPUnit
En nuestro ejemplo, hemos trabajado con Eclipse, y nuestra aplicacion, tal y como comente en SDCA – Sistema de datos contables para un autónomo – Diseño de la BBDD , tiene instalado Composer, para facilitar la gestión de paquetes; en ese entorno, solo tengo que ir, con la terminal, a la raíz de mi aplicación, donde se encuentra el «composer.json», y teclear
composer require --dev phpunit/phpunit ^9.1
Esto nos instalara la ultima version de PHPUnit en nuestro proyecto, al haber indicado «–dev» lo considerará una dependencia de desarrollo, por lo que no lo incluirá en produccion
Tambien tengo que decir que esta version requiere PHP7.4 o superior, por lo que deberéis actualizar PHP si no estáis trabajando con esa version, y, aseguraros que el «PEAR» que tenéis se corresponde con la version de PHP que estáis instalando. Con Xampp puede que tengáis algún problema, y espero escribir un articulo sobre ello, en un futuro corto.
Por ultimo, os dejo una visión de como ha quedado nuestro fichero «composer.json» al terminar esto, y de paso, observad las definiciones de los autoload!!!!!!
La estructura de nuestro proyecto
Si normalmente sabemos de la necesidad de que un proyecto este ordenado, cuando vamos a escribir unos cientos de módulos mas, eso pasa a ser imprescindible.
En nuestro ejemplo, disponemos de una estructura de paquetes como esta
Bien, y nosotros vamos a escribir como mínimo un modulo por clase, en el que se realizara las pruebas, luego, nuestra estructura para test, será una colección de carpetas idénticas a las contenidas en src, pero guardadas bajo una carpeta «test«, algo como esto.
Si os acostumbráis a esta estructura, y un día queréis programar en Java y utilizar Junit, os daréis cuenta de las ventajas que aporta esta estructura reflejo.
Y de momento, nada mas. Mañana mismo me pongo con la siguiente parte del articulo, en donde escribiremos el módulo de prueba para la clase Co_usuarios
