Estás a cuarenta metros de profundidad, buceando en condiciones de baja visibilidad. Un pecio hundido hace una veintena de años, en proceso de descomposición, pero con casco y estructuras principales muy visibles. Congrios de dos metros, que asoman su cabeza espectantes, podrían destrozar un balón de baloncesto como si fuera mantequilla. Entras en busca de la codiciada carga del barco perdido, pero te das cuenta de repente que has estado perdiendo el aire. ¡Tienes algo roto! No has revisado bien: el regulador, jacket, botella, sólo has hecho lo indispensable, rápido y corriendo, para llegar lo antes posible a la preciada carga hundida.. y ahora te encuentras en un serio aprieto. Te quedan 5 minutos de aire y tienes que hacer descompresión. No puedes subir a superficie directamente o tus células estallarán. Menuda situación..

Desarrollo orientado a pruebas – ¿Qué es el TDD?

El caso de este buceador a cuarenta metros, es la situación en la que es fácil estar si se entrega un proyecto web sin probarlo bien. En las entregas, desearás estar seguro de que lo que entregas, está en perfecto funcionamiento, valga la redundancia. Si no has automatizado las pruebas, es lo que te puede pasar cuando publicas o entregas una modificación. Puede que arreglando un pequeño detalle, se te haya colado algún error en el otro extremo de la web. Somos humanos, y cuánto mayor es la web, más fácil es que una modificación en un extremo rompa algo del otro extremo de la web.

Todo esto se puede evitar en gran medida mediante lo que se llama el Desarrollo Orientado a Pruebas, que en inglés se dice Test Driven Development, o TDD para los amigos. En esta metodología de desarrollo web se priorizan las pruebas automáticas, ya sean funcionales como unitarias. Para después ponerse manos a la obra con el resto del trabajo de desarrollo. En esta metodología de desarrollo, siempre existirán una batería de pruebas que se hacen automáticamente, que recorrerán la página web automáticamente en busca de fallos de extremo a extremo.

PHPUnit - desarrollo orientado a pruebas

Todo habrá pasado por la batería de pruebas antes de llegar a producción. Es decir, si por el camino algo ha ido mal, saltará la alarma. Así podrás dormir tranquilo, será muy improbable de que algún error se haya colado a producción. Si hubiera alguna modificación que haya roto alguna parte de la web tendrás tiempo de resolverlo.

En la imagen de arriba tenemos los resultados de cobertura visuales de las pruebas automáticas. Es decir, qué tanto por ciento de cada parte de la aplicación web se ha probado automáticamente. Es conveniente llevar estos porcentajes de cobertura a un 80-90%. Y en caso de aplicaciones muy críticas conviene alcanzar un 100%. En este proyecto, conviene programarle unas cuantas pruebas más, para subir el porcentaje ya que un 57% es poco 😉

El TDD en Symfony

En Symfony, como framework de desarrollo web de referencia en el mundo de las webs, tiene integradas una serie de herramientas para facilitar las pruebas automáticas:

  • Puente con PHPUnit integrado en el proyecto.
  • DOMCrawler para navegar y encontrar elementos mientras hacemos las pruebas funcionales.
  • BrowserKit para hacer peticiones locales a nuestro proyecto.
  • Las clases TestCase para pruebas unitarias, y WebTestCase para las pruebas funcionales.
  • La clase general KernelTestCase para lanzar un kernel completo de Symfony y así probar en un entorno isolado.
  • La clase CommandTester para probar comandos de consola.
  • Etcétera..

En el TDD, lo primero que hay que tener en mente, son las pruebas automáticas. Cuando ya tenemos el esqueleto de la aplicación web, lo siguiente que hacemos son las pruebas automáticas. Y así vamos probando siempre que vamos construyendo. Antes de querer pasar a producción cualquier nueva modificación, hay que pasar esta batería de pruebas. En un proyecto de prueba se puede ver así:

PHPUnit testing - Desarrollo orientado a pruebas

Aquí se puede ver que tenemos 5 ficheros de pruebas, con 95 puntos de comprobación en este proyecto.

En nuestro proyecto con Symfony Flex, Symfony 4

Para añadir el puente de PHPUnit a nuestro proyecto ejecutamos desde línea de comandos lo siguiente:

composer require --dev symfony/phpunit-bridge

Para ejecutar las pruebas automáticas ejecutamos lo siguiente:

./bin/phpunit

Si queremos ver los resultados de cobertura, la cantidad de código que se ha probado automáticamente podemos ejecutar lo siguiente:

./bin/phpunit --coverage-html public/coverage/

Si lanzamos nuestro servidor local:

composer require --dev server
php bin/console server:start

..podremos consultar qué tal van nuestros tests automáticos en: http://localhost:8000/coverage/

Esto es el principio para tu tranquilidad. Es la mejor forma de dormir tranquilos, teniendo la certeza de que el proyecto en el que estamos trabajando no se ha roto por algún cambio. Así con esto automatizado, nos evitamos muchos problemas y dolores de cabeza, al publicar proyectos nuevos o actualizaciones.

¿Prefieres que te echemos un cable?

A veces, ciertas cosas pueden sonar a chino. Estaremos encantados de conocer tu proyecto para darte una solución personalizada.

¡Contáctanos!

¿Te has quedado con ganas de más?

Echa un vistazo a otros posts del blog. ¡Nos esforzamos por crear contenido útil para ti!

¡Ver posts!

    Deja un comentario

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *