Hazlo bien con CodeceptJS: Una introducción a las pruebas de extremo a extremo supercargadas

Así que lo llamaría prueba de extremo a extremo supercargada. Bueno, porque puedo, y porque realmente disfruto de las pruebas con Concept.js. Mi nombre es Michael, y te presentaré esta herramienta y te mostraré el problema que realmente resuelve. Soy de Kiev, Ucrania. En realidad soy un desarrollador web, pero también trabajo como ingeniero de automatización de pruebas para practicar, para ver cómo las personas, qué problemas tienen con las pruebas automatizadas. Y así es como llevo esta experiencia a marcos de prueba de código abierto como, sorpresa, Concept.js.

Así que sí, también soy el desarrollador principal de Concept.js, pero también me gusta hacer pruebas con Concept.js. Bueno, creo que es justo decir esto. Comencé mi viaje hacia los marcos de prueba de código abierto con mi proyecto anterior, Conception, que es muy popular en la comunidad de PHP. Y Concept.js toma esta experiencia y la lleva a un nuevo nivel y se adentra en el ecosistema de JavaScript. En la actualidad, trabajo para mi propia empresa y estamos construyendo un sistema de gestión de pruebas para pruebas automatizadas, Testomato. Testomato se enfoca en pruebas de JavaScript, por lo que si tienes un desastre total con tus pruebas, Testomato puede organizarlo para ti. Esa es la idea.

Así que comenzaría mi charla con la pregunta sobre ¿recuerdas esos buenos y viejos tiempos cuando todo era bastante predecible, todo era estable, y no estoy hablando de cosas como que podías viajar a todos los lugares que quisieras, podías hablar con las personas que quisieras. Estoy hablando solo de cosas de ingeniería que anteriormente teníamos solo una herramienta. Se llamaba Selenium, y lo usábamos para probar todo lo relacionado con el navegador. Si necesitabas Selenium, probablemente elegirías Java. Si necesitas, tal vez necesitarás Python o Ruby, pero elegirías Selenium. Era una decisión segura. No había absolutamente ninguna alternativa en aquellos días.

Pero hoy vivimos en la era de la incertidumbre. El JavaScript se encontró, y creó un maravilloso ecosistema de diferentes herramientas. Y hoy elegir la herramienta adecuada para el trabajo es una pregunta difícil, porque tenemos Cypress, tenemos WebDriver, Playwright, Cucumber, Jest, Mocha. Y bueno, cuántas cosas necesitas aprender hoy para elegir la herramienta adecuada para el trabajo. Definitivamente vivimos en la era de la incertidumbre, y mucho más estrés trae las preguntas que intento enumerar cuando le pregunto a un cliente sobre un nuevo proyecto de automatización de pruebas. porque podemos comenzar a escribir pruebas, pero luego el cliente sale y dice, oye, aprendí sobre BDD ayer. Es tan impresionante. Quiero escribir esta prueba yo mismo en lenguaje Gherkin. ¿Puede nuestra herramienta escribir pruebas en Gherkin? Hmm, buena pregunta. Especialmente si ya tenemos nuestras pruebas no en Gherkin, sino en JavaScript, ¿podemos introducir fácilmente el nivel BDD encima de eso? Oh, el cliente llegó. Necesito Internet Explorer. Me odiarás por esto, pero necesitamos Internet Explorer porque tengo muchos clientes enterprise. ¿Puede tu herramienta cambiar fácilmente a Enterprise Explorer sobre la marcha cuando todas las pruebas, especialmente con BDD en todas las cosas que ya hemos escrito? Esa es una buena pregunta. Oye, el cliente vuelve. Necesito soporte para Safari. Bueno, Safari está bastante bien. Safari es un navegador moderno. Todos lo usan. Y si nuestra herramienta puede hacer Safari o no, esto también puede ser complicado para algunos tipos de herramientas. Pero debemos estar preparados para todos esos cambios todo el tiempo. ¿Podemos ajustar nuestras pruebas para que se ejecuten en todos esos diferentes entornos? Y especialmente para los navegadores móviles porque el mundo se vuelve móvil, y probar en móviles también es un requisito difícil que el cliente puede no ser plenamente consciente al comienzo del viaje pero preguntará cuando tengas algunas pruebas y te pedirán, ejecuta esta prueba en móvil y esta prueba. Entonces, el navegador móvil también puede ser un nuevo requisito. Y en contra de la era de la incertidumbre, no sabemos qué nueva herramienta de automatización de pruebas surgirá este año porque cada año, alguna buena herramienta de automatización de pruebas emerge.

El año pasado recibimos Playwright de Microsoft. Anteriormente obtuvimos Puppeteer, también estaba TestCafe, Cypress. Así que muchas herramientas nuevas están saliendo aquí y allá y tal vez en 2021 nos traiga algo nuevo. ¿Podremos cambiar a ello? Si es tan nuevo, un supuesto asesino de Cypress, un asesino de Playwright, cualquier cosa absolutamente asesina, tal vez deberíamos probarlo también y sin reescribir las pruebas. ¿Es eso posible alguna vez? Esta pregunta la podemos dirigir a concept.js.

Concept.js es un marco de pruebas de estilo BDD. El estilo BDD significa que escribimos nuestras pruebas en un lenguaje similar al humano y tratamos de evitar algunas interacciones complejas de JavaScript y mantener el código lo más legible posible. Y se centra únicamente en las pruebas del navegador lo que lo diferencia de Mocha o Jest pero tiene una API para todos los motores de navegadores.

Entonces, a diferencia de Cypress, concept.js no intenta ejecutar las pruebas por sí mismo. Delega la ejecución a Playwright, a WebDriver, a Protractor, a Puppeteer, a Testcafe. Por lo tanto, concept.js puede cambiar fácilmente la ejecución entre todos esos motores. Y sí, viene con soporte para BDD con Cucumber en caso de que tu cliente realmente lo necesite. Así que aquí está la prueba en concept.js. Como puedes ver, puedes leerla. Sí, es muy sencillo. No necesitas consultar la documentación. No necesitas pensar en lo que está sucediendo en la pantalla. Ya puedes entender todo lo que está sucediendo aquí. Así que concept.js admite hacer clic en nombres de botones, en etiquetas de botones, en CSS, XPAS, todo. Así que puedes hacer que tus pruebas sean lo más legibles posible al escribir pruebas con concept.js.

Concept.js es bastante fácil de instalar. Es solo un comando. Y de forma predeterminada, viene con PlayWrite porque creo que PlayWrite es realmente impresionante en la actualidad. Y elegiría PlayWrite para mi próxima prueba porque es multi-navegador, multiplataforma, y se lo recomendaría a todos. Pero concept.js se puede instalar sin PlayWrite. Es solo una decisión basada en opiniones que puedes cambiar fácilmente. Así que concept.js viene con un proyecto de demostración, pero comencemos con un nuevo proyecto vacío. Deberás inicializar tus pruebas y seleccionar el motor de navegador. Selecciona el navegador, responde esta aburrida pregunta, y crea una primera prueba. Cuando hayamos hecho esto, llegaremos a la primera prueba creada.

La prueba solo debe contener estos dos pasos: abrir una página y lanzar la función Pulse. Ahora, me gustaría presentarte otra función genial de concept.js, que es Pulse. Pulse reemplaza todas tus pruebas que necesitan ejecutarse después de abrir la página. Así que Pulse es increíble.

Permíteme mostrarte. Estoy ejecutando esta prueba. Se está ejecutando en mi navegador. Abre el sitio web de Airbnb con Playwright. Y después de que se abre la página, la ejecución se pausa, así que ahora puedo abrir mis herramientas de desarrollo y pensar qué debo hacer a continuación. Ves, este es mi terminal. Ves este mensaje de Pulse aquí. Así que cuando no estoy seguro de qué debo probar, por dónde debo empezar, simplemente comienzo con un Pulse. La página se abre y las herramientas de desarrollo también se abren. Puedo navegar por la página, seleccionar diferentes elementos, probar diferentes comandos y así sucesivamente.

Por ejemplo, déjame mostrarte cómo tratamos con los calendarios aquí. Tengo mis herramientas de desarrollo abiertas en la parte inferior y la terminal a la derecha. Escribo mis comandos en la terminal y verifico si puedo encontrar elementos con los localizadores que acabo de seleccionar. Por ejemplo, descubrí que puedo seleccionar una fecha con el localizador de ID de prueba y lo intento. Sí, funcionó y se seleccionó la fecha. Luego presiono la tecla Enter y veo que el navegador actúa en consecuencia. Así que continúo realizando mis acciones escribiendo comandos, seleccionando elementos, y esto es como si estuviera escribiendo mis pruebas en tiempo real.

Cuando terminamos de seleccionar comandos y terminamos nuestras pruebas, volvemos al editor y nuestros comandos se guardaron en el archivo de historial de la CLI. Lo que hago es copiar mis comandos de este archivo, solo se guardaron los comandos exitosos. Elimino la pausa y voilà, aquí está mi prueba. Incluye todos los comandos que tenía. Así que ejecuté este navegador una vez y no hice suposiciones a ciegas, ni búsquedas a ciegas. Ejecuté la prueba y aquí está. Por cierto, pude escribir mis comentarios y tengo un excelente soporte de autocompletado. Así que todos pueden comenzar con Concept.js porque los comentarios son muy fáciles de entender. Por ejemplo, esta es la prueba que terminamos.

¿Qué tan difícil es cambiar de motor de navegador? Básicamente así, vamos a la configuración y cambiamos de player a web driver y podemos esperar que la prueba se ejecute de manera similar, no igual, porque ves que el web driver funcionará un poco diferente que play, ¿verdad? Tal vez en algunos puntos veas fallas, pero la idea es que las cosas comunes son las mismas, por lo que todas las diferencias se pueden solucionar fácilmente agregando un poco de peso, cambiando algún localizador. Entonces, para la mayoría de las pruebas, la transición funcionará sin problemas para el 95% del código de prueba. No requerirás ningún cambio.

Entonces esto resuelve el problema que mencioné. Entonces, si necesitas transformar tu prueba a play, ¿verdad?, puedes transformarla fácilmente. Si necesitas web driver, simplemente cambia la configuración. Tal vez necesites cambiar a prueba de café para admitir Internet Explorer, esto también funciona. Y sí, esto es realmente poderoso.

Concept.js también viene con una interfaz de usuario incorporada y ejecutores de pruebas interactivos gráficos que pueden mostrar un informe paso a paso de todas las pruebas ejecutadas. Por lo tanto, puedes usarlo como una herramienta de informes. Puedes ver cómo va la ejecución. Y también tiene algunas características que tiene la Terminal, pero algunas más avanzadas también. Por ejemplo, puedes mantener un navegador sin volver a ejecutar la prueba y cambiar fácilmente entre el modo headless y el modo de ventana.

También en Concept.js, tenemos soporte de informes incorporado. Por lo tanto, una de las mejores herramientas compatibles aquí es Concept.UI sin duda, porque los Concept.UI están hechos para Concept.js. Pero la captura de pantalla a la derecha no es de Concept.UI. Tal vez ya adivinaste qué es. Es el informe allure. Por lo tanto, Concept.js tiene soporte incorporado para informes allure. En caso de que necesites mejores informes para mostrar a tus clientes o simplemente para ver qué sucedió en CI en producción para que puedas rastrear los cambios en tus pruebas. También admitimos tecnologías más empresariales como Report Portal. Tenemos un agente oficial de Concept.js en la organización de Report Portal. Por lo tanto, puedes tener informes de Report Portal con Concept.js y Testomatio, la herramienta en la que estoy trabajando también intenta brindar mejores informes para tus pruebas de extremo a extremo. Por lo tanto, los informes son bastante importantes en las pruebas de hoy en día porque todo se puede mostrar desde una consola y seguramente tus gerentes, tus clientes no mirarán la consola para ver qué pruebas se aprobaron, qué pruebas no, por qué razones. Quieren una interfaz gráfica limpia y agradable para comprender esto. Es por eso que Concept.js ofrece tantas opciones para informes porque según tu presupuesto, según tus condiciones, puedes elegir la herramienta que desees. Por cierto, todas esas tres herramientas son absolutamente de código abierto. Puedes comenzar a trabajar con ellas y con Concept.js hoy mismo.

Permíteme resumir algunas características importantes de Concept.js. No mencionaré las características de Concept.js porque ya has oído hablar de cambiar entre motores, pausa interactiva, sintaxis fácil de aprender. ¿Qué más tenemos? Y sí, ya lo mostré un poco. Tal vez ya lo hayas visto.

Además, tenemos soporte incorporado para la ejecución en paralelo mediante trabajadores. Una API muy moderna y elegante. Puedes escribir tus propios ejecutores personalizados para paralelizar tus pruebas como desees. Por ejemplo, puedes agrupar las pruebas en dos grupos, en dos navegadores de Firefox, o hacer cuatro grupos en Safari. Puedes dividir las pruebas como desees en grupos, llevar tantos navegadores como necesites y tener ejecuciones en paralelo y un informe único después de esto. Eso es realmente genial.

También tenemos una solución incorporada y simple para pasos fallidos. Intenta automáticamente los pasos nuevamente. Entonces, si algún elemento no se encuentra en la página en el primer intento, ni siquiera lo notarás. Concept.js lo intentará nuevamente y esperará a que aparezca sin siquiera notificarte. Funciona para cualquier comando, clic, ver, lo que sea. Simplemente funciona, no lo toques y estarás bien.

Concept.js utiliza el concepto tradicional de objetos de página y está integrado en el marco de trabajo para que puedas refactorizar fácilmente tu código para que sea fácil de usar en otras pruebas. Los objetos de página, objetos de pasos y objetos de datos están todos integrados. Como mencioné anteriormente, tenemos soporte para Cucumber BDD basado en Concept.js. Esto es realmente increíble porque puedes combinar el verdadero BDD con especificaciones en JavaScript, como las pruebas de Concept.js. Esto es importante porque no todas las pruebas deben escribirse de manera verdaderamente BDD, ya que no todas las pruebas son características. Porque necesitas tener pruebas de regresión para la caja. Mi punto es que debes combinar el enfoque BDD con el enfoque clásico y solo el marco de pruebas Concept.js te permite hacer esto.

Otra característica genial que me gusta mucho es si tienes una API y puedes comunicarte con tu aplicación a través de esa API, por ejemplo, puedes crear fixtures a través de esta API, eliminar fixtures. Y es mucho más fácil hacerlo a través de la interfaz de API REST en lugar de la interfaz web. Por lo tanto, puedes combinarlos fácilmente. Y esos son mis puntos finales. Concept.js es un marco de pruebas y lo que lo diferencia de los demás es que se centra en las pruebas de extremo a extremo sin ejecutar tus pruebas de extremo a extremo por sí mismo. Intenta brindar la mejor experiencia de usuario para hacer que las pruebas sean lo más fáciles posible. Concept.js es completamente gratuito y de código abierto.

Puedes contribuir en ello. Ya hay grandes y pequeñas empresas que utilizan Concept.js y se están uniendo a él. Así que únete a nuestro equipo, únete a nuestra community, prueba Concept.js por ti mismo para comprobarlo y funciona realmente genial con Playwright. Gracias por ver, mi nombre es Michael y nos vemos pronto.

Sí, pensé que Cypress tendría incluso más números aquí. Estoy bastante impresionado de que alguien esté utilizando Concept.js. Lo que quería mostrar con estas encuestas es que hay diferentes motores y para diferentes propósitos, puedes elegir las herramientas que se ajusten mejor a ti. Así que creo que Cypress es muy popular porque es muy amigable para los desarrolladores y ha captado a muchos desarrolladores que no les gustaba testing, que no querían hacer esto y las pruebas de navegador les parecían complicadas porque siempre era un producto de Selenium con el que lidiar. Y por otro lado, WebDriver es más para ingenieros de QA que trabajan en pruebas de extremo a extremo porque necesitan un mayor control del navegador. Así que creo que aquí hay dos audiencias y sí, son bastante diferentes pero necesitamos involucrar a todos ellos para colaborar y hacer mejores pruebas.

Eso tiene mucho sentido. También hemos empezado a recibir preguntas para tu charla. Así que tengo algunas preguntas para ti, si está bien. Voy a empezar con ellas y no voy a mencionar los nombres de las personas que han hecho las preguntas porque voy a destrozar el nombre, así que no tiene sentido. Pero una de las primeras preguntas fue, ¿funciona CodeSapJS en modo multi-navegador? Por ejemplo, un par de navegadores están interactuando entre sí.

Claro, claro. Implementamos esta característica hace como un año, no, hace dos años. Así que sí, hace bastante tiempo. Funcionaba, estaba bien probado y sí, puedes usarlo. O dos navegadores diferentes si lo deseas.

Vale, vale. Eso está muy bien. Alguien hizo el comentario de que CodeSap tiene diferentes compromisos como lo hace Cypress. Cypress, por ejemplo, dice que no tiene mucho soporte de pestañas y no puedes usarlo para controlar dos navegadores al mismo tiempo. ¿Cómo se compara CodeSap en relación a eso?

CodeSap no resuelve estos problemas. Los delega a los motores que ya resuelven este problema. Por eso prefiero herramientas como Playwright o Puppeteer que tienen un control total del navegador, y por eso no me gusta Cypress para la mayoría de mi trabajo de testing. Pero sí, esto es una preferencia del usuario y lo que mejor se adapte a tu trabajo. Así que si necesitas probar una aplicación de una sola página con los componentes individuales, Cypress está muy bien. Pero si necesitas un control total del navegador y más y más características, CodeSap js es mejor porque puedes elegir el motor mientras escribes tus pruebas.

Entonces, la base de código está creciendo, pero aún puedes elegir un motor mejor si lo necesitas. Eso tiene mucho sentido y me gusta, especialmente porque la gente se inclinaba mucho hacia uno de los motores disponibles.

¿Cómo maneja CodeSap.js las cosas que tardan en aparecer en la página? Por ejemplo, una aplicación de una sola página. Perdón, ¿cómo, qué? ¿Cómo maneja CodeSap.js las cosas que tardan en aparecer? Es decir, que tardan en cargarse en la página porque es una página grande, como una aplicación de una sola página donde todo tiene que cargarse antes de poder interactuar con ello.

Sí, el problema con las aplicaciones de una sola página es que no sabemos si se han cargado o no. Nunca nos dice nada al respecto. Así que no hay un estado de esta aplicación. Tenemos diferentes estrategias para esto. La estrategia predeterminada es externa, intentando cada paso. Por lo tanto, cada paso en la prueba se volverá a intentar automáticamente en caso de fallo. Tenemos esperas explícitas. Por lo tanto, puedes esperar cualquier cosa que desees. Puedes añadir reintentos manuales. Y si tienes aplicaciones muy, muy malas que no son muy inestables, puedes reintentar el escenario completo. Así es como también funciona. Creo que esas son todas las estrategias, pero tal vez haya algunas más. Pero estas son las que uso regularmente. Y funcionan.

La gente quiere saber más sobre las restricciones de usar CodeSapp.js. ¿Existen restricciones como la carga de archivos o el trabajo con iframes? ¿Cuáles son algunas de las limitaciones del framework? Eso son preguntas bastante incorrectas porque realmente lo siento como la audiencia de Cypress y no puedes hacerlo porque CodeSapp.js no controla el navegador. Se delega a Playwright y Playwright no tiene restricciones. Así que la única restricción que debes entender es que CodeSapp.js no puede hacer todo lo que Playwright puede. Por lo tanto, necesitas escribir algo de código de Playwright o código de Puppeteer o código de WebDriver si necesitas utilizar algunas APIs muy especiales. Pero sí, puedes hacer todo lo que puedes hacer con Playwright, Puppeteer, WebDriver, etc., con CodeSapp.js.

De acuerdo, eso tiene mucho sentido. Eso tiene mucho sentido. Alguien quiere saber si se puede generar una prueba de CodeSapp.js grabando interacciones en un navegador. Soy muy escéptico acerca de esta idea. Así que lo intenté, y cambié a este modo de pausa interactiva. Y encontré que esto es mucho más efectivo porque no solo estoy grabando mis acciones, sino que las estoy probando en tiempo real, lo cual no puedo hacer con un grabador. Así que esto es mucho más flexible y efectivo para mí como tester. Eso es realmente bueno.

Hay muchas preguntas de Michael. No podremos responder a todas ellas. Tomaremos una más. Entonces, cuando CodeSapp realiza la función de respuesta automática, ¿se graba solo en el primer intento exitoso, o por ejemplo, en el tercer intento? La persona que hace la pregunta tiene preocupación acerca de los reintentos que pueden ocultar errores intermitentes. Entonces, ¿cómo ocurre la grabación de reintentos automáticos? Creo que es una pregunta bastante técnica. No estoy seguro de si podré responderla a tiempo, pero me gustaría hablar de ello después de mi charla en la sala.

Oh, perfecto. En ese caso, es perfecto para mí recordarles a todos que pueden unirse a ti en tu sala de oradores en spatial.chat. El enlace para unirse está en la línea de tiempo de la transmisión en vivo, y por favor únete a Michael para más preguntas. No tendremos tiempo para responder más. Gracias, Michael, por la charla y por acompañarme en las preguntas y respuestas. Fue realmente bueno. Gracias por invitarme. Gracias por la oportunidad de estar aquí contigo. Y gracias a todos por ver.