 Buenos días, mi nombre es Steve Fenty y soy británico, inglés de hecho, y todavía europeo y también soy falo gastránico desde hace 5 o 6 años. Y trabajo para GravityFonds como programador. Si no conocéis GravityFonds es un plugin para WordPress que permite a cualquier usuario crear formularios muy avanzados para su site de WordPress. También soy fundador de GravityFlow. GravityFlow es otro plugin para WordPress que permite a cualquier organización automatizar sus procesos de negocio basados en formularios creados con GravityFonds. Y lo que voy a compartir esta mañana es como nosotros en GravityFonds y GravityFlow estamos continuamente mejorando la fiabilidad de nuestros productos con pruebas de navegador automatizadas. Aquí tenemos un ejemplo, un tiempo real de pruebas de navegador. Como ves a la derecha tenemos el script de pruebas que está controlando el navegador. Cada vez que arranca una nueva prueba abre una nueva ventana de navegador. Está comprobando todo nuestro trabajo como programador. Está comprobando el PHP, el CSS, JavaScript, SQL, todo. Y por eso en inglés se llaman también pruebas end-to-end de principio a fin. Entonces lo que estamos viendo son pruebas reales de clientes reales de GravityFlow. ¿Por qué hacemos esto? Para asegurar que cada vez que sacamos una nueva versión de nuestro producto sigue funcionando los procesos de negocio de nuestros clientes existentes. Y esto es muy importante porque si rompemos algo tiene un impacto muy grande en un cliente. Eso es muy problemático. Para una empresa puede ser un problema muy grande. En el caso de GravityFonds tenemos unos dos millones de sites. Entonces, si cada pequeño problema que tenemos en el código puede causar una pesería enorme para el equipo de soporte. Al final de las pruebas nos genera un informe y luego lo vemos como es. ¿Por qué hacemos las pruebas? Acabo de mencionar la razón principal. Queremos evitar errores de regresión en nuestros productos. Cada vez que sacamos una nueva versión queremos asegurar que no hay problemas con lo que teníamos funcionando antes. Pero hay otras razones también. Personalmente como programador a mí me viene muy bien escribir las pruebas. Simplemente porque me obliga a ponerme en el lugar del usuario para comprobar que funciona correctamente mi código. Esto es una experiencia importante porque como programadores tenemos tendencias de utilizar nuestras atajos normales. Entrutimos los meus datos cada vez, pero escribiendo la prueba nos obliga a hacer exactamente lo que tiene que hacer el usuario. Rellenamos este campo, pulsamos este botón. Paso por paso nos obliga a hacer y he encontrado errores en mi código antes de compartirlo con un compañero. Pero también hay más razones todavía. Dependiendo de cómo trabajáis en vuestro sistema de desarrollo, a veces se puede hacer la prueba antes de hacer el código. En estos casos, estos pruebas se llaman pruebas de aceptación. Porque podemos hacer la prueba, por ejemplo, de una nueva funcionalidad, por ejemplo, para una cajita de login. La prueba tiene que definir... Rellenamos el campo de usuario, luego de contraseña. Luego damos el botón de enviar. Y tenemos que ver en la página la palabra bienvenida. Luego hacemos el código. Y si funciona la prueba, damos por hecho que funciona el código. En este caso se llaman pruebas de aceptación. Pero no tiene que ser solo para nueva funcionalidad. También puede ser para errores en el código que ya tenemos funcionando. Por ejemplo, un cliente nos envía un ticket al equipo de su porte. El equipo de su porte tiene varias opciones ahora. Si confirme que es un error, puede escribir los pasos para reproducir el problema y lo envía al equipo de desarrollo. O podría hacer un vídeo demostrando al equipo de desarrollo cómo puede reproducir el problema. Pero ahora tiene una tercera opción que es mucho mejor, igual de rápido. Y garantiza que este error nunca puede volver a pasar nunca más. Entonces, el equipo de desarrollo en nuestros equipos también hacen las pruebas de aceptación. Y esto es una cosa muy importante que quiero transmitir esta mañana. Que no es el dominio solo del programador, no es solo para los técnicos, también es para el equipo de su porte, es para el director de cuentas, es para el jefe de producto. Todo el mundo tiene que estar involucrado en hacer las pruebas de navegador. ¿Cuándo sería el mejor momento de implementar las pruebas de navegador? Podréis volver el lunes y empezar ya. Pero nosotros lo implementamos después de haber hecho tres mecanismos de calidad antes. Y recomiendo hacer estas cosas también. Las pruebas de navegador no reemplazan estos tres mecanismos de calidad. Primero, hemos hecho un montón de pruebas de unidad y de integración utilizando PHP Unit. Esto no reemplaza estos. También tenemos una política de revisión de código por otro programador. Entonces, cada línea que entra en nuestro producto está revisado y probado por otro programador. Y tercero, tenemos también una fase de pruebas humanos, de un equipo pequeño que hace las pruebas antes de sacar una nueva versión. Entonces, no reemplazan estos mecanismos de calidad. Añade otro capa para asegurar la fiabilidad de nuestros proyectos o productos. Ahora quiero explicar cómo funciona las pruebas, lo que habéis visto en el vídeo. Que parecíamos sencillo, que el script ahí en el terminal estaba controlando el navegador. Pero si te fijaste bien, había otra pestaña en el terminal que estaba trabajando como loco. Y eso es la parte importante porque en esa pestaña estaba corriendo un servidor especial entre medio que convierte nuestras instrucciones de nuestra prueba a instrucciones al navegador. Entonces, parece un poco así. Tenemos el navegador, en este caso Chrome, y luego dos herramientas que trabajan juntos en un servidor escuchando en el puerto 4444. Escucha nuestras instrucciones y lo convierte en instrucciones para un navegador. Y de aquí podríamos hacer una presentación entera de cómo se puede programar Selenium y ChromeDriver para controlar el navegador. Pero sería otra presentación distinta. Porque mi enfoque hoy es recomendaros, como hemos hecho en nuestras organizaciones, involucrar a todas las personas dentro de la organización. Entonces, esto no es solo para programadores, esto es para todos. Entonces, nosotros utilizamos otra herramienta debajo de todo este stack, que se llama Code Deception, que nos permite hacer mucho más fácil las pruebas. No solo utilizamos Code Deception, pero utilizamos un modelo especial para Code Deception, que se llama WP Browser. Code Deception simplemente es un conjunto de herramientas que nos permite hacer varios tipos de pruebas. Por ejemplo, pruebas de aceptación, pruebas funcionales, pruebas de unidad. Y además tiene muy buena integración con PHP Stomps y lo utilizáis. Y para nosotros es la forma más fácil de involucrar todo el equipo de nuestra organización. Aquí tenemos un ejemplo muy sencillo de una prueba hecho en Code Deception. Como ves, muy sencillo, no puede ser más sencillo. Simplemente, no sé si se ve bien ahí, pero pone I fulfilled, nombre Steve. Lo que simplemente rellena el campo con la etiqueta nombre, con el valor de Steve. Luego, puse un botón de enviar y luego para comprobar que todo funciona correctamente, tiene que ver la palabra gracias. Esto es más sencillo, imposible. Si te estás preguntando qué significa el variable I, en este caso, es una instancia de la clase de Acceptance Tester de Code Deception. Y esta clase tiene un montón de métodos que nos permite controlar el navegador. Y no voy a hacer un listado de todos los métodos porque se puede encontrar en la documentación, en Code Deception. Y cualquier cosa que quieres hacer con el navegador, subir ficheros, cambiar de usuario, lo puedes hacer con estos métodos. No solo eso. Pero también hay una extensión de navegador para Chrome para Code Deception que va grabando cada cosa que haces en la página y lo va escribiendo todas las líneas de la prueba. Más fácil, imposible. Bueno, miento. A veces las pruebas no funcionan correctamente. Entonces, por eso estamos aquí, los técnicos. Para ayudar a la gente que no son tan técnicos, ayudarles cuando sus pruebas dejan de funcionar o no funcionan correctamente. Por ejemplo, en el primer ejemplo, quizás no funciona el click en el link de Logout. ¿Por qué? Porque quizás no encontramos la palabra Logout en la página o quizás aparece cinco veces en la página. Entonces, ¿dónde tenemos que pulsar? En el segundo ejemplo, definimos exactamente dónde deberíamos pulsar. Tiene que pulsar en el link de Logout dentro del elemento que tiene la clase nav, por ejemplo. O podemos utilizar un selector CSS como en el tercer ejemplo. Pero estamos obligando a Code Deception a adivinar qué tipo de localizador estamos utilizando. Y esto tarda y no es muy eficaz. Entonces, la forma más eficaz y lo más favorable, si tenéis que ayudar o arreglar una prueba que no funciona correctamente, lo mejor es utilizar un localizador estricto y decir a Code Deception exactamente qué tipo de localizador estás utilizando. En este caso, por ejemplo, está diciendo que tiene que tener la clase Logout, pero también hay otros tipos de localizadores estrictos. CSS, link en lo peor de los casos, XPath. La verdad es que en la mayoría de los casos, el primero va a funcionar, pero tenéis que saber cómo arreglarlo si hay problemas. Si todo funciona correctamente, nos da un informe Code Deception con todas las pruebas en verde, si todo ha salido bien, con la duración de cada prueba. Y si ha fallado una prueba, nos muestra cada paso que ha hecho para llegar al fallo. En el momento de hacer el fallo, nos graba un pantallazo y nos graba también el HTML en ese momento. Entonces, con esa información, ya tienes normalmente suficiente información para arreglar o la prueba o nuestro código. En este caso, envió el formulario. Estaba esperando un texto, pero no lo encontró. Y no sé qué pasaba exactamente en esta prueba. Quizás es porque no podía ver el botón. Entonces quizás había que hacer un scroll to para ver el botón. Vale, he mencionado que utilizamos Code Deception y un modelo especial para WordPress de Code Deception que se llama UWP Browser. Y esto se puede encontrar en GitHub, en el repositorio de Luca Tume UWP Browser. Y este modelo tiene un montón de otros modelos que son muy útiles. Y os animo a investigar todos los modelos que tienen. Son muy buenos, es muy buen modelo. Nosotros solo utilizamos dos. UWP WebDriver y UWP Browser. Y este modelo nos aporta también más métodos a nuestra clase de acceptance testa para facilitar las pruebas de WordPress. Por ejemplo, I login as admin. I login as otro usuario. Si queremos ir directamente a la página de plugins, I am on plugins page. Si queremos comprobar que el usuario no tiene los permisos suficientes, I see WP die page. Montón de métodos. Lo que puedes imaginar, lo puedes encontrar. Y si no lo encuentras, lo puedes hacer tú. Nosotros hemos creado un método especial para ir a la página de workflow para el proyecto de Gravity Flow. Os recuerdo que podéis ver todo esto en el repositorio de Gravity Flow. Hemos hecho un método I am on workflow page. Y luego pasamos la página donde queremos ir. Y el navegador va ahí. Y estos métodos se definen en el fichero de acceptance testa.php. Que nos crea automáticamente code-ception cuando seguimos las instrucciones de instalación. O simplemente copias y pegas lo que ves en el repositorio de Gravity Flow. Qué recomiendo. Hasta ahora, muy fácil, ¿verdad? Entonces, ¿por qué no está todo haciendo esto a todo el mundo? Pues esto es la razón. Porque la mayoría de la gente que intenta hacer esto, la mayoría frena por la configuración. Entonces, esta presentación, voy a hacer mucha hincapié en cómo configurarlo. No solo para nosotros, los técnicos, pero también para el resto de la organización. Para que sea muy fácil para toda la organización hacer esto. Y al final verás que podemos arrancar todas las pruebas con un solo comando. Pero para llegar ahí, voy a explicar cómo configurar lo que hemos visto en el vídeo de la forma más bruta. Entonces, esto es lo que yo tenía que configurar todos los módulos, ¿vale? Todos los componentes que tenía que instalar para que funciona lo que habéis visto en el vídeo. No se ve muy bien, ¿no? Hace falta una jota de acá. Hay que descargar de la web de Selenium WebDriver. Hay que descargar de la web de ChromeDriver el arremiente de ChromeDriver. Hay que configurar los permisos para que sean ejecutables. Y luego hay que arrancar los dos juntos con este comando que parece... ¡Eh! ¡Mucho mejor! Vale. Y esto, esta primera parte se encarga... Esto se encarga de la parte de la arremiente que estaba funcionando en la otra pistana escondida que tenía ahí corriendo como loco en el puerto 4444. Esto va a ser divertido, ¿vale? También necesitamos codeception, claramente. Y utilizamos Compose para instalarlo. Necesitamos un site dedicado a estas pruebas. No vale el site de dos horarios ni staging de producción. Necesitamos un site dedicado a las pruebas de navegador porque vais a perder los datos al principio de cada prueba. Además necesitamos un fichero de configuración de codeception de en formato yml. Y este fichero tiene que estar correctamente configurado para apuntar al servidor de ChromeDriver y nuestro web de pruebas. Y no otro web porque lo vamos a destruir. Y luego para arrancar las pruebas utilizamos el comando codecept run dentro de la carpeta de Vendubin, ¿vale? Pero, vale. Entonces, esto es un ejemplo de un fichero de configuración de codeception para hacer las pruebas lo que hemos visto en el vídeo. Tenemos que decidir a codeception dónde están las pruebas. En el caso de Gravity Flow está en la carpeta de tests bar acceptance tests. Y luego tenemos que configurar los dos modelos que he mencionado que utilizamos de codeception que son UWP Loader y UWP WebDriver. UWP Loader se encarga de resetear nuestra web. Entonces, tiene que saber dónde están los ficheros de la web, leer las credenciales de las bases de datos. También tiene que saber los plugins que tiene que estar instalados y activados. Luego, tiene que, el UWP WebDriver tiene que saber dónde va a hacer las pruebas, dónde está la web, qué tipo de navegador está utilizando, dónde está nuestro servidor de ChromeDriver en puerto 4444, en este caso en localhost. Y también tiene que saber las credenciales para entrar como admin para hacer las pruebas, como el método de login as admin. Vale, esto todo muy fácil para los técnicos, para escuchar todo eso aquí, ¿verdad? Nosotros somos capaces de hacer esto, seguir un poco de instrucciones y podríamos montar esto fácilmente. Pero imagina, diciendo esto a vuestros compañeros que están en los otros tracks, en nuestras presentaciones. Yo he intentado, no funciona. Entonces, vamos a simplificarlo, utilizando Docker. Y lo voy a simplificar en dos pasos. Uno que es muy sencillo y otro que requiere un poco más conocimiento de Docker. Primero, vamos a quitar por completo la parte del servidor de ChromeDriver, que es la parte difícil de descargar Selenium en ChromeDriver y arrancar todo juntos. Vamos a quitarlo por medio, ¿vale? Vamos a reemplazarlo con un solo comando, que es Docker run Selenium standalone Chrome. Entonces, con Docker instalado, y este comando simplemente descarga el imagen de Chrome standalone desde el repositorio de Selenium y descarga todo lo que necesita para hacer todas las pruebas. Y para dejar el Chrome driver escuchando en el puerto 4444. Eso está muy bien, porque después de cinco minutos de hacer las pruebas para nosotros, es molesto un poco tener el navegador abriendo cada segundo. Es bastante chulo verlo ahí al principio, pero cuando tienes 140 pruebas, como tenemos en Paragravity Forms, esto y tarda una hora y media en hacer, tenemos que seguir trabajando. Entonces, esto nos da la ventaja de tener un navegador escondido dentro de un contenedor de Docker, de Linux, con todo escondido y contenido ahí. Entonces, no tenemos que verlo. Podemos conectar a través de una conexión VNC con el puerto 59.00. Eso está bien, eso es un avance, pero seguimos con la necesidad de tener codeception y composa. Tenemos que tener un site de WordPress que tiene que ser lo mismo en todos los puestos de trabajo, en todo el equipo. Tiene que ser igual en todas las mismas versiones, porque si no, las pruebas no van a funcionar correctamente. Tenemos que asegurar que el fichero de configuración de codeception es la correcta, porque podemos hacer un fallo muy grande. Entonces, montamos la forma de simplificar incluso más es montar todo dentro de contenedores de Docker utilizando Docker Compose. Entonces, no sé si se ve aquí, pero hay un contenedor para cada servicio que necesitamos. Selenium Chrome más VNC, WordPress las últimas ficheros, la última versión, la base de datos para WordPress. Necesitamos un contenedor para codeception y WP Browser. Y este último es un poco especial, porque tenemos que definirlo nosotros, porque nosotros tenemos que definir nuestras dependencias. En el caso de Gravity Flow, la dependencia es Gravity Forms. En vuestro caso, tendréis otras dependencias y podéis copiar y pagar lo que tenemos hecho para Gravity Flow. Pero estos tres, los Selenium, WordPress y las base de datos utilizamos la imagen de Docker oficial de cada servicio. Entonces, es muy sencillo. Luego, una vez que tenemos todo en marcha, todo configurado y contenido en una especie de red privada, la única cosa que tenemos que hacer es arrancar las pruebas con un solo comando que sería Docker Compose, Run, Code Deception, Run. Y así, todo el mundo en nuestra organización puede escribir y también utilizar todas las pruebas de aceptación que tenemos. Al final, nos genera un informe en HTML en la carpeta de Output en nuestro equipo local, no en el contenedor. Y esto es muy importante, porque no queremos ir buscando en el contenedor para todos los ficheros. Y además, queremos asegurar que cada cambio que hacemos en local está reflejado también en las pruebas en nuestro entorno de Docker. Entonces, tenemos que mapear los contenedores al equipo de local. Y voy a enseñar un ejemplo de cómo nosotros tenemos esto montado con Docker Compose. Esto es un fichero de configuración de Docker Compose que no se ve nada. Pero los detalles no son importantes. Lo que es importante es que se ve que hay tres servicios, los Chrome Wordpress y MySQL, que utilizan la imagen oficial y luego tenemos la configuración de Codeception, que utilizamos el build del Dockerfile que está en la raíz del proyecto. Y no voy a enseñarlo ahora, porque esto no es una presentación sobre Docker, pero es mirando en el repository de Gravity Flow. Se puede copiar y pegar lo que nosotros tenemos. Teniendo esto tan portable que se puede utilizar en Mac, Linux, Windows, en todos los equipos, para toda la organización, también nos aporta otra ventaja. Podemos utilizar la misma configuración en nuestro sistema de integración continua. Nosotros utilizamos CircleCI que para nosotros funciona muy bien. Aquí tenemos un ejemplo, ves que ha hecho cuatro veces las pruebas y una vez ha fallado. Entrando en el detalle de CircleCI para ver el detalle de una prueba que lo hizo bien, se ve que hay una pequeña resumen de las pruebas, y si hay fallos, no se cree un resumen de los fallos, en la persistaña de artifacts podemos encontrar el enforme y los errores. Pero lo que quiero destacar aquí son los cuatro contenerores, 0, 1, 2 y 3, que utilizamos en CircleCI y hay un botón para añadir más contenerores. Y esto nos permite hacer las pruebas en paralelo. Esto es muy importante porque las pruebas de navegador pueden tardar mucho tiempo, entonces si lo podemos hacer en paralelo, ayuda muchísimo. En lugar de esperar una hora y media para hacer las pruebas de Gravity Forms, por ejemplo, podemos esperar mucho menos tiempo utilizando CircleCI. Hasta ahora solo he estado hablando del navegador de Chrome. Además, Chrome dentro de un contenedor de Linux que no es lo más habitual. Entonces, tenemos que hacer las pruebas también en navegadores reales. Otros tipos de sistemas operativos y los dispositivos de móvil reales. ¿Cómo hacemos eso? Pues nosotros lo conseguimos utilizando servicios externos. Por ejemplo, hay varios. Source Labs es uno. Nosotros utilizamos Browsestack. Browsestack, como en CircleCI, tiene un plan gratuito para el código abierto. Y como se ve aquí, eso es un pantallazo de las pruebas que ha hecho Browsestack. En este caso, en Chrome, en distintas versiones de Chrome, pero en distintos sistemas operativos. A la derecha, se ve el vídeo de principio al fin de la prueba. Y eso es muy útil para ver los problemas y luego logs de sobra con pantallazos. Por ejemplo, aquí tenemos las pruebas en un Samsung Galaxy Note 8 y se ve que está haciendo las pruebas en paralelo porque había configurado CircleCI para conectar a Browsestack para hacer todas las pruebas a la vez en paralelo. Cuatro contenedores, cuatro navegadores en Browsestack. Por último, algunos consejos. Repito esto. Es muy importante. Asegura que no te quedas como la única persona en la organización que sabe hacer las pruebas de aceptación. Es un... Ya no me había dicho cinco. Tiene que involucrar todas las personas. Organizar las pruebas, numerarlos, porque si falla una prueba es muy difícil encontrarlos y no le das un número. Puedes organizarlo por un grupo, simplemente añadiendo un comentario al principio de la prueba. Cuidado con la pregenación. Tuvimos un caso que un fallo dejó una prueba dejó de funcionar porque habíamos añadido demasiados formularios y el formulario que estaba buscando la prueba había pasado a paginar dos. Entonces hay que pensar esto cuando estás haciendo las pruebas. Muy importante, la atención. Esa prueba que enseñaron funciona en local. Pero, si una vez que empiezas a hacerlo en Docker y en otros browser stack y en otros sistemas tienes que esperar la respuesta. No puedes hacer sí directamente hacer click. Hace wait, antes de sí. También se puede utilizar código dentro de las pruebas. Se puede utilizar código de JavaScript, por ejemplo. En este caso, hay Execute JavaScript está escondiendo un seleccionador de fechas. Pero también se puede utilizar cualquier función de WordPress o de tu plugin o tema. Pero, ojo, los procesos son diferentes. El proceso que está utilizando nuestra prueba es diferente al proceso que está utilizando el navegador. Entonces, eso significa que no funcionan los filtros. Pero, hay un truco. Se puede utilizar un MU plugin para activarlo automáticamente y para detectar en la URL cuando queremos activar el filtro, que es como lo hacemos también. También utilizamos MU plugins para hacer pruebas de correos también. Porque creamos automáticamente un nuevo post para cada correo que enviamos. Entonces, así podemos ir a la URL del post y comprobar que el texto es correcto del correo y el enlace funciona correctamente y va a otra página que genera otro correo y podemos encargar todas las pruebas y correos así. Ojo con los widgets porque pueden contaminar las pruebas. Por ejemplo, los posts recientes pueden contener texto que estás buscando en la prueba. Entonces, nosotros quitamos todos los widgets utilizando un plugin MU. Y por último, muchas gracias. Espero que vais a implantar esto en nuestra organización entera. Porque os garantizo si volvéis a hacerlo si volvéis a la oficina para implementar esto y lo conseguís vais a aumentar la fiabilidad de vuestros productos y los proyectos muchísimo como hemos hecho nosotros. Y por lo tanto también vas a ganar mucho más confianza por parte de los clientes en vuestros servicios. Si queréis más información ahí tienes mi blog. También el blog de delicious brains tiene una forma muy parecida de hacerlo. Voy a estar ahí en el stand. Muchísimas gracias. Muchas gracias.