A finales del año pasado me llegó la posibilidad de colaboración a modo de consultoría con Funidelia, un comercio electrónico de disfraces. Un comercio electrónico que además va como un tiro, por cierto.
Me contactaron para echarles una mano para empezar con el testing funcional (o de sistema, o end-to-end, o...). Ya que al parecer intentaron en el pasado ponerse con ello pero, como ocurre en muchas ocasiones, el día a día de una startup no permite que el equipo técnico pueda focalizarse en ello.
Así que tras una reunión inicial y alguna otra conversación teníamos claro que mi papel era sentar unas bases sobre las que ellos pudieran seguir.
¿Cuáles eran esas bases?:
- Implementar casos los tests automáticos para la parte más crítica del negocio: los diferentes puntos dentro del proceso de compra.
- Saber cuanto antes cuando se rompe un test. Así que se pueda lanzar correctamente desde un servidor de integración continua (que en su caso era un jenkins) sobre entornos de desarrollo.
- Además del entorno de desarrollo que pudieran lanzar contra entornos de staging, o incluso producción. Teniendo en cuenta que la misma base de código del comercio electrónico se ejecuta en diferentes instancias y configuraciones (por país).
- También se debían lanzar los tests con diferentes navegadores, es crítico que funcione correctamente con todos lo navegadores mayoritarios.
- El lenguaje de programación a utilizar iba a ser PHP, ya que es el utilizado por el equipo.
Una cosa que estuvimos hablando fue el que los tests sólo cubrirían los escenarios optimistas del proceso de compra, esto es cuando se supone que al usuario todo le va bien y termina con su compra de disfraces hecha. No sólo para lo que yo iba a hacer, si no también para cuando el equipo siguiera evolucionando las baterías de tests. Al final son tests lentos, frágiles y mantenerlos tiene bastante coste, pero luego volvemos a ello.
Las herramientas:
Hacía mucho que no programaba en PHP y no estoy para nada al día de sus novedades, pero para esto estábamos de acuerdo que no creíamos que iba a ser un gran problema.
Aunque no estuviera muy al día sí tenía referencias de cosas como composer para gestionar las dependencias y era el punto de partida.
En cuanto al framework de testing se me pasó un momento por la cabeza el cacharrear con behat, pero como al final iban a ser tests sólo para los programadores me parecía añadir una indirección que no aportaba nada; así que tiramos a lo seguro con PHPUnit, que ir con algún framewrk xUnit es ir sobre seguro.
Para el lanzamiento de acciones de navegador también tenía claro la elección con Selenium Webdriver y el cliente PHP implementado por la gente de facebook.
Mientras para que para el soporte de ejecución frente a diferentes entornos, monté algo de código a medida para poder cargar configuraciones de ficheros json a partir de un parámetro enviado al comando de ejecución de la batería de tests.
Page Objects:
Y ya respecto a los propios tests, como escribía algo más arriba, los funcionales suelen ser considerados frágiles y lentos.
Decimos lentos para el contexto de que no nos sirven para dar feedback rápido de si algún cambio que hayamos introducido en el código ha roto algo, si los intentas usar para ello serán una tortura para tu flow. Si a alguno no le suena la Pirámide de Test siempre puede informarse de ello en la web de Fowler.
Y decimos frágiles principalmente porque cualquier cambio de maquetación html por pequeño que sea puede romper el test: un texto, un class, un id... Así que, salvo que la UI no evolucione, suelen resultar caros de mantener frente a otros tipos de tests.
Una forma de abaratar bastante el mantenimiento de esos tests es el uso Page Objects. De modo que para cada página (aunque también podríamos tener Page Objects de elementos comunes, como quizás un menú de navegación) que queremos que participe en los tests abstraeremos sus detalles de implementación para utilizarlo como un objeto en cada caso de test, reduciendo de esta manera la duplicidad de código y mejorando la legibilidad de los propios tests.
En los Page Objects expondremos tanto métodos que crean/llevan a otros Page Objects como otros que lanzarán acciones para que sean ejecutadas en el navegador (un click, completar un formulario...) y de los que opcionalmente esperaremos algo en el retorno.
Además en mi caso implemento los Page Objects con la responsabilidad de los asserts en el propio Page Object. Ahí decido lo mucho o poco que quiero acoplarlo a la maquetación exponiéndolo como un assert con un lenguaje más de negocio. Esto lo comento porque al implementar Page Objects existen 2 vertientes ligeramente diferentes: incluir los asserts o proveer un modo para que el test sea el responsable de cómo se le hacen los asserts y así separar responsabilidades. El propio resumen final que enlazo, por lo general, desaconseja lo asserts en estos objetos; aunque a mi por el momento no me ha resultado problemático el hacerlo y se adapta más a mi gusto.
Y ya desde un punto de vista más práctico y sin meterme en detalle, este es como quedaría test de añadir un producto al carro de la compra:
Como se puede ver en el código, se mantiene encapsulado entre esos objetos. Podría cambiar completamente la maquetación de la UI y tendríamos que cambiar sólo la implementación de los Page Objects (que no es poco). Otro tema es que, por razones de diseño o negocio cambiara la lógica de navegación, claro.
