Conclusiones

En este PFC hemos intentado dar visibilidad a las distintas herramientas para la creación de tests automáticos y las distintas metodologías que podemos realizar. Para ello, hemos intentado dar respuesta a los planteamientos que planteábamos en el anteproyecto, basándonos en cinco objetivos:

• Estudiar como testar una clase en PHP. Para dar respuesta a este apartado hemos creado una clase que mejoraba el tipo de datos string de PHP y hemos creado test unitarios en dos frameworks de testeo, PHPUnit y Atoum. En la memoria de este PFC hemos expuesto algunos ejemplos de los tests, intentando dar visibilidad a las diferencias estas dos herramientas, aunque demostrando que ambas son válidas para el objetivo de este punto.

• Testo de bases de datos. En el capítulo 5 hemos explicado los distintos puntos que debemos considerar cuando planteamos realizar tests a un desarrollo con dependencias con bases de datos. Hemos planteado un ejemplo en el que el código testeado realizaba consultas a bases de datos, mostrando hincapié en la complejidad que este tipo de test de integración (hay que destacar que no sse pueden considerar test unitarios) debido a la dificultad para crear un entorno bajo control, similar a producción.

• En el capítulo 6 hemos trabajado en dar respuesta al objetivo del uso de mocks, creando una extensión de Monolog para enviar mensajes logs a Apache Solr. En el desarrollo de este objetivo vimos que existía una gran cantidad de librerias para gestionar mocks por lo que decidimos profundizar en este punto, con la misión de exponer la mejor opción para cada situación. Respecto a todas estas librerías hemos llegado a una conclusión: Siempre que sea posible, es preferible utilizar Prophecy frente a las otras alternativas. Llegamos a la conclusión puesto que es la herramienta más estricta, lo cual nos exigirá implementar nuestro código siguiendo buenas prácticas, frente a atajos que nos facilitan herramientas. Consideramos como herramientas de mocks poco recomendables las que permiten utilizar mocks parciales, mocks de clases no existentes, etc.

• El objetivo de nuestro anteproyecto en el que pretendíamos documentar TDD ha sido satisfecho en el capítulo 7. En este capítulo hemos explicado en qué consiste TDD, cuales son los pasos a seguir y hemos realizado dos ejemplos. El primero, el juego para niños Fizzbuzz, ha sido desarrollado utilizando PHPUnit, con el objetivo de presentar la metodología con una herramienta de propósito general de testing. El segundo hemos implementado una pequeña relación entre dos clases utilizando Phpspec, como herramienta de propósito específico para TDD. En el capítulo 8 hemos explicado BDD utilizando un ejemplo con Behat.

• En nuestro anteproyecto pusimos como objetivo testear con Selenium una aplicación que pueda existir en producción. Este objetivo lo hemos cumplimentado en los capítulos 8 y 9, aunque no hemos usado directamente Selenium, sino que hemos usado otras herramientas más modernas, que a su vez, utilizar Selenium u otros simuladores de navegadores. En el capítulo 8 testamos algunas funcionalidades básicas de WordPress utilizando Behat y en el capítulo 9 repetimos el ejercicio con Codeception, con el objetivo de estudiar distintas alternativas. Debido a las grandes diferencias que existen entre estas dos herramientas, no podemos concluir sobre el uso de una frente a la otra. Ambas herramientas ofrecen ventajas e inconvenientes, no siendo excluyentes. En nuestra opinión, algunas partes de un proyecto podrían estar testeadas utilizando Behat y otras utilizando Codeception. De esta forma se podrían obtener las ventajas de las dos herramientas.

• En lo referente a integración continua, hemos realizado dos ejemplos utilizando dos herramientas muy distintas: Jenkins y Travis CI. Podemos concluir, y como lo está haciendo la comunidad PHP, que utilizar una herramienta como Travis CI puede ser mejor solución para proyectos de código abierto alojados en sitios como GitHub. Así lo vimos en el capítulo 12 cuando repasamos los tests de Silex y Slim. Esta solución ofrece la posibilidad de ver el estado de integración para cualquier usuario, he incluso nos da la oportunidad de ver el estado de la integración si decidimos colaborar con un proyecto. Por otra parte, utilizar Jenkins en entornos privados es recomendable, dado que la flexibilidad es total.

Tras la realización de este proyecto podemos concluir que trabajar con generación de test ofrece una gran cantidad de ventajas frente a no hacerlo. Algunas de estas ventajas son cuantificables a través de las herramientas de análisis estático de código. Podemos llegar a esta conclusión debido a algunas prácticas que hay que mantener cuando escribimos código testeable:

• Composición frente a herencia.
• Código con disposición a inyección de dependencias.
• Principio de simple responsabilidad.
• Con el objetivo de facilitar la cobertura, mejor complejidad ciclomática.
• Mayor legibilidad del código.
• Uso de interfaces en el código de testing, por lo que ayuda a la comprensión del código.
• ...

Todos los puntos mencionados anteriormente pueden ser alcanzados sin testeo automático, pero no se puede realizar testeo si el código no cumple estos puntos, por lo que por necesidad, un código con testeo automático deberá ser mejor que uno sin testeo.

Las ventajas mencionadas anteriormente justifican solo mejoras a nivel de calidad de código, pero no hay que olvidar que el testeo automático ofrece otras ventajas, como hemos visto a lo largo de este PFC, como son regresión, menor índice de errores,

Herramientas utilizadas

Para realizar este PFC hemos realizado:

• Vim, como editor de código PHP para los distintos ejemplos y Gedit como editor de textos para la memoria, en formato Markdown

• PHP 5.5.30 instalado en mi portátil para realizar los distintos ejemplos.

Futuras lineas de trabajo

Dado que el desarrollo de un PFC debe estar acotado en tiempo, hay algunas lineas de investigación que, o bien no hemos abordado, o no hemos profundizado todo lo que podríamos haber llegado. Algunos de los puntos que consideramos haber dejado de lado son:

• En este documento hemos intentado incluir herramientas mantenidas por la comunidad y hemos dejado de lado otras abandonadas como pueden ser SimpleTest, SnapTest, etc. Una revisión de estas herramientas nos podría haber enseñado la forma en la que se trabaja anteriormente.

• En las próximas fechas a la edición de este documento saldrá a la luz la versión PHP 7. En este documento no hemos abordado los posibles cambios del lenguaje con respecto a la forma en la que testeamos, cuando pensamos que algunos cambios de PHP 7 cambiarán la forma de testear. Por ejemplo, uno de los cambios que promete PHP 7 y que merece la pena destacar aquí por el impacto que tendrá en la forma que testeamos en PHP es el tipado estricto. Hasta el momento, verificar en un test que la devolución de un método o función tenía un tipo concreto era habitual, dado que PHP 5 y versiones anteriores es de tipado dinámico. A partir de PHP 7 el tipo de datos de la devolución de una función puede ser definido en la función, por lo que no será necesrario testearlo más. Esto puede que afecte a la forma en la que usamos las herramientas de testing.

• Con este cambio de versión, todos los frameworks que hemos analizado en este documento deberían de evolucionar para adaptarse al lenguaje. Algunos de estas herramientas tienen prevista una fecha por la lanzar la versión correspondiente a PHP 7, como PHPUnit, que en diciembre de 2016 prevé tener la versión 6.0, que dará soporte únicamente a PHP 7.

• Otra linea de investigación, aunque no estrictamente relacionada con el testing, pero sí con la calidad de código sería la relacionada con las herramientas de análisis estático de código, métricas de calidad de código, etc. Estas herramientas, al igual que la práctica de crear tests, tiene un objetivo común con el testing: mejorar la calidad del software y minimizar los errores. Produndizar en estas herramientas es valioso para cualquier lenguaje de programación.

• En este PFC nos hemos centrado en un único lenguaje de programación: PHP. Sin embargo, hay multitud de lenguajes. Este estudio podría realizarse a casi cualquier lenguaje de programación, desde Java hasta Erlang. Estudiar como crear test automáticos para las herramientas que usamos, desde el punto de vista de desarrollador de software, es una tarea tremendamente útil y en algunos sectores del mundo laboral, imprescindible.

Además, no podemos sabemos qué ideas surgirán de la comunidad de desarrollo, o que práctica será importada de otra comunidad. Estudiar y aprender sobre lenguajes de programación, o sobre partes tan pequeñas como el testeo automático, puede ser extendido y profundizado extensamente.