Construyendo una suite de pruebas significativa que no sea todo E2E

Recording available for Multipass and Full ticket holders
Please login if you have one.
Rate this content
Bookmark

Todos somos enseñados a seguir la Pirámide de Pruebas pero la realidad es que construimos el Árbol de Pruebas de Navidad. En esta masterclass, David te explicará cómo desglosar proyectos y poner las pruebas donde necesitan estar. Al final de la masterclass, podrás actualizar tus proyectos para que cualquiera y todos puedan empezar a contribuir y realmente vivir según "La calidad es el trabajo de todos".


Te guiará a través de:

  • - Pruebas de Componentes
  • - Pruebas de API
  • - Pruebas de Regresión Visual
  • - Pruebas A11Y


También te explicará cómo configurar todo esto en tu pipeline de CI/CD para que puedas obtener ciclos de feedback más cortos y rápidos.

89 min
29 Jan, 2024

AI Generated Video Summary

La masterclass de hoy cubrió temas como la optimización del pipeline de CI/CD, la escalabilidad y la confianza en CI/CD, TDD y la confianza en las pruebas, la configuración de Nightwatch para pruebas móviles, la exploración de Nightwatch y la configuración de entornos, las pruebas unitarias con Nightwatch y estilos de JavaScript, las pruebas de API y el mocking con Nightwatch, la gestión de la complejidad en el diseño de software, la modularidad y la composición en el diseño de software, la complejidad de los navegadores y las pruebas de componentes, las pruebas de componentes y la complejidad de la UI, las pruebas visuales y de accesibilidad en Nightwatch, las mejores prácticas para las pruebas de regresión visual y de extremo a extremo, y los desafíos de la testabilidad en los frameworks de front-end.

1. Introducción a las pruebas y CI/CD

Short description:

Hola a todos. Mi nombre es David. Soy el jefe de código abierto en Browser Stack y he trabajado en Selenium durante 15 años. Hoy, voy a mostrarles el pipeline de CI/CD de Mozilla y discutir cómo obtener el máximo provecho de su pipeline de CI/CD.

Hola a todos. Mi nombre es David. Estoy en AutomatedTester en cualquier red social. Soy el jefe de código abierto en Browser Stack. Y Browser Stack es una plataforma para escalar sus necesidades de testing para hacer diferentes cosas. Soy el presidente de un grupo de trabajo de W3C sobre herramientas de testing y navegadores. El editor de la especificación WebDriver. He trabajado en Selenium durante 15 años. He trabajado en Lightwatch y he liderado el proyecto Nightwatch durante los últimos tres años y medio. Antes de Browser Stack, trabajé en Firefox durante nueve años y medio. Así que tengo una buena idea de los navegadores y cosas así. Curiosamente, gran parte de mi tiempo cuando estaba en Mozilla se dedicó a mejorar el pipeline de CI CD de Mozilla. ¿Cómo podemos hacerlo más rápido? Y así, hoy, voy a mostrarles cómo es el pipeline de CI CD de Mozilla al principio. Porque creo que es importante. Y para mostrar que algunas cosas son simplemente aterradoras. Pero no tiene por qué ser así. Y si simplemente lo desglosamos en el problema más pequeño, podemos partir de ahí. Así que las reglas, como he dicho varias veces, interrúmpanme si tienen alguna pregunta, interrúmpanme mientras hablo. Si no entienden algo, probablemente haya alguien más que tampoco lo entienda. Prefiero simplemente aclarar eso. Y podemos hacer esto tan interactivo como quieran. No hay expectativa de que tengan las cámaras encendidas o algo así. Si no quieren hacer eso, eso también es perfectamente aceptable. Pero si tienen preguntas, háganlas.

Así que, hoy, voy a hablar sobre la comprensión del problema. Cuando se trata de testing, cómo las personas desglosan sus problemas. Instalación. Así que, aquí es donde voy a mostrarles Nightwatch. Pero en su mayoría, deberían poder tomar los mismos conceptos exactos y aplicarlos a otras herramientas. Algunas herramientas podrían no ser capaces de hacer todo. Pero pueden obtener el mismo resultado exacto al observar cómo abordan sus problemas y luego avanzar desde ahí. Voy a guiarlos a través de los diferentes tipos de testing. Lo siento, sé que todos ustedes conocen las pruebas unitarias, de integración y de extremo a extremo. Pero hay mucho matiz en todas esas áreas. Y así, quiero pasar por algunas de esas. Y al final, repasaremos cómo obtener el máximo provecho de su pipeline de CI, CD y cómo pienso en escalar estos problemas. Así que, una de las cosas más importantes al mirar todo esto es que deberíamos trabajar desde la creencia de que las computadoras deberían estar esperando a los humanos. Los humanos no deberían estar esperando a las computadoras. Esta es una cita de Christian Lognito. Christian solía trabajar en Mozilla cuando yo estaba allí. Ahora es, creo, el Director de Productividad de Ingeniería en Robinhood. Robinhood es una plataforma de trading con sede en los EE. UU. Pero cuando pensamos en todas las cosas que intentamos hacer cuando se trata de testing, cómo desglosamos nuestros problemas, es ¿cómo podemos hacer que las computadoras nos esperen en lugar de que nosotros esperemos a las computadoras? Sé que en mi carrera, he visto a muchas personas contándome sobre los conjuntos de pruebas de Selenium que tardan 24 horas en ejecutarse. Eso no es realmente útil cuando es así. Ni siquiera necesita ser Selenium en ese punto. Pero si sus pruebas de extremo a extremo están tardando tanto, ¿hay realmente mucho valor? Porque para cuando encuentren algo que ha fallado, podría haber fallado un cambio menor en su interfaz de usuario. Así que, por ejemplo, si están en Selenium, pueden decirle que apunte a coordenadas y luego haga algo en una coordenada. Y eso ya no está en esa coordenada. Y luego tienen que pasar por todo este ciclo de nuevo, ¿verdad? Una y otra vez.

2. Optimizando el Pipeline de CI/CD

Short description:

Y lleva demasiado tiempo. Necesitamos desglosar el problema y centrarnos en lo que funciona bien, no en lo que se ve bien. Los bucles de retroalimentación y la reducción de distracciones mejoran la velocidad y la resolución de problemas. Encuentra la mejor herramienta para el trabajo y considera cómo escalar el pipeline de CI/CD.

Y lleva demasiado, demasiado tiempo. Así que necesitamos pensar en cómo podemos desglosar el problema. Y si lleva mucho tiempo, porque no hay otra manera, que así sea. Y aquí es donde creo que es, quería mostrarles, estaba pensando en ello hoy y debería haber puesto un enlace, pero lo pondré en el canal. Así que Treeherder es de Mozilla, y es público para todos, es la visualización del pipeline de CI-CD de Mozilla. Construir un navegador es bastante complejo y tanto que necesitas pensar en un navegador en estos días de la misma manera que pensarías en un sistema operativo. Tiene que saber cómo renderizar cosas. Tiene sus propios lenguajes de programación que están en él. Simplemente sabe qué hacer. Y cuando me fui hace unos cuatro años, algo como esto aquí, esta tarea, podría llevar en algún lugar en la región de dos mil quinientas horas de cálculo para completar. El tiempo total de reloj para completar esto probablemente sería en algún lugar en la región de como seis, siete horas. Pero es porque necesita ejecutar cosas en Android, y cuando en Android, tiene diferentes estilos de compilación. Así que como tienes Optimal Builds, PGO Builds, ASAN es para verificar la seguridad de la memoria. Tienes tus builds debug, cosas así. Y cuando lo miras en diferentes versiones de sistemas operativos, simplemente crece exponencialmente. Y es bastante aterrador pensar en ello, pero es realmente importante que cuando nosotros miramos estos problemas para nuestros propios pipelines de CI-CD y cosas así, intentamos hacer las cosas, los bucles de retroalimentación lo más rápido posible. ThoughtWorks solía tener la creencia de que si tu CI estaba tardando más de 10 minutos, estás fallando. Creo que es un poco extremo, pero es el concepto. Así que necesitamos volver a lo básico y lo básico aquí, creo que realmente estamos pensando en lo que estamos testing, cómo lo estamos testing. Veo a mucha gente en, discúlpame, en varias plataformas diciéndome, diciendo como, tengo mis pruebas de Playwright funcionando. Son increíbles. Son mucho más rápidas que Selenium, cosas así. Y luego un poco más abajo en la línea, dirán, bueno, en realidad, está tomando la misma cantidad de tiempo. Mis pruebas de Cypress están funcionando más rápido que Selenium, y mis pruebas de Cypress están funcionando más lento. Y el problema es, cuando miran la cosa, ven y cómo están construyendo software y haciendo cosas como eso. El enfoque está en el lugar equivocado, generalmente. Y esto no es para decir que necesitas hacer una cosa u otra. Es moderación en todo lo que hacemos. Porque si volvemos a la creencia original de las computadoras deberían estar esperando a los humanos, no los humanos esperando a las computadoras, como dijo Christian, pensamos en los problemas de una manera ligeramente diferente a como, necesito probar esta cosa, y así es como voy a abordarlo. Así que, cuando estamos mirando el proceso de desarrollo, porque cuando se reduce a ello, las pruebas de extremo a extremo, Selenium, Playwright, Cypress, lo que sea, ¿verdad? es desarrollo. No es como si pudiera ser desarrollo con enfoque en testing, pero está trabajando contra un proceso de desarrollo. Así que, deberíamos dejar de centrarnos en Shiny.

3. Optimizando el Proceso de Pruebas

Short description:

Concéntrate en lo que funciona bien, no en lo que se ve bien. Detén las distracciones y mejora la velocidad. Encuentra la mejor herramienta para el trabajo y considera escalar el pipeline de CI/CD.

Lo que esto significa para mí es que, como, la gente debería centrarse en lo que funciona bien, no en lo que potencialmente se verá bien en mi CV, o lo que está de moda. Desafortunadamente, el mundo de JavaScript tiene esta visión de tener esta creencia de pasar de un objeto Shiny a otro. Ya sea un marco de front-end, un servidor backend, un proceso de construcción, un linter, todas estas cosas, enfócate en Boring en lugar de enfocarte en Shiny. Necesitamos pensar en los bucles de retroalimentación. ¿Cómo podemos sacar el máximo provecho de nuestra suite de pruebas y nuestras respuestas en el menor tiempo posible? Porque lo más importante es, necesitamos detener las distracciones. Cuando comencé mi carrera, había esta creencia de hacer la web super rápida, y mucho de eso fue impulsado por Yahoo, que tenía muchos datos que mostraban que, si algo tardaba más de, creo que eran 800 milisegundos, la gente empezaría a abandonar. Cuando comencé mi carrera, fue alrededor de 2005, así que las velocidades de internet no eran super rápidas, pero la gente se iba, y cuanto más tiempo pasaba la cantidad de personas que se iban crecía considerablemente porque se distraían, simplemente no querían esperar más. Cosas así. Todos hemos visto el XKCD de las dos personas peleando con espadas, y el jefe diciendo, hey, ¿qué estás haciendo? Vuelve al trabajo. Y ellos responden, Estoy compilando. Oh, está bien, entonces. Necesitamos detener las distracciones. Cuando pensamos en eso en nuestras pruebas, va a mejorar enormemente la velocidad, pero también la forma en que abordamos diferentes cosas, diferentes problemas en diferentes momentos. Creo que eso es, sé que dije que lo haría al final, el pipeline de CI/CD, pero si trabajamos hacia atrás, y en este caso, no voy a decir que una herramienta es mejor que otra, pero espero que puedas mirarlo y pensar en cuáles son las características que estamos buscando en las herramientas, ¿verdad? y luego desde allí puedes encontrar lo que se ajusta bien a ti, porque es solo una herramienta. Todo lo que siempre debemos mirar es solo una herramienta, y debemos encontrar la mejor herramienta para el trabajo, lo mejor que pueda mantener a la gente en movimiento. Entonces, cuando se trata de cómo miramos el CI/CD pipeline, es cómo lo ejecutamos, es como ¿vamos a hacer esto en todo? Entonces, ¿lo hacemos en todas las solicitudes de extracción? Por ejemplo, si estás usando GitHub, ¿hacemos CI/CD en cada X número de commits y decimos, bueno, podemos confiar en esta cantidad de commits a la vez y podemos retroceder esa cantidad de commits? Y luego el diseño. ¿Cómo podemos escalar nuestro CI/CD

QnA

Escalado y Confianza en CI/CD

Short description:

Considera escalar horizontalmente para las pruebas de integración. Revisa y soluciona los problemas de confianza en CI. Nunca confíes en una prueba que no ha fallado. Usa TDD como punto de partida.

¿realmente rápido? Y esta es la parte importante. En su mayoría, como, en realidad, volveré a tree header. La forma en que todo esto está organizado es que todo intenta escalar horizontalmente, principalmente porque, como, puedes crear trabajos, y cada trabajo sería independiente del otro. ¿Cuántas veces podemos hacer eso? Porque, como, podríamos tener, como, como, nuestras pruebas de integración, están haciendo cosas. Están hablando con una database. ¿Podemos escalar esa parte de forma horizontal? ¿Estamos hablando con un servidor dedicado que está ejecutando nuestras cosas? ¿Eso puede escalar? Los data dentro de eso, ¿están escalados? ¿Es un desarrollo cosa? Y entonces, necesitamos pensar en desglosar cada uno de los problemas. Pero con suerte, a medida que desglosamos cada uno de estos, podemos llegar a cómo vamos a organizar esto. Porque la forma en que lo organizas afectará tu velocidad. E idealmente, quieres llegar a una etapa en la que tu suite de pruebas debería tomar tu CICD debería tomar tanto tiempo como tu prueba más larga, con suerte. Pero ese no es siempre el caso, y no siempre es factible. Pero eso es más o menos a lo que queremos apuntar. Y cuanto más apuntemos a eso, con suerte, podremos escalar mejor. Pero hay muchas cosas que necesitamos pensar. No solo como una facilidad de configuración, sino como costo, mantenimiento, cosas así. Es una de las razones por las que trabajo en una empresa como BrowserStack, aunque Selenium tiene un herramienta llamada Selenium Grid, que te permite crear tu propia versión de BrowserStack. El costo de mantenerlo, a menos que seas una gran empresa, probablemente seguirá siendo mayor que el costo de usar un tercero para hacer esto. Entonces, BrowserStack es uno. Hay muchos otros. Pero podemos partir de ahí. Y deberíamos revisar regularmente nuestro CI para asegurarnos de que está agregando valor a nuestro proceso de desarrollo. Las pruebas que están ahí, ¿están pasando? ¿Están haciendo las cosas que esperábamos? Cuando estaba en TestJS Summit y estaba hablando con algunas personas, nos contaban cómo usan Percy, que es una herramienta de testing visual de BrowserStack. Pero no confían en nosotros. Lo usan en su CI. Siempre está fallando. Y entonces, no confían en nosotros. Y entonces, como, cuando digo revisar regularmente tu CI, es, como, ¿qué son las cosas en las que confiamos? ¿Cuáles son las cosas en las que no confiamos? ¿Y cómo podemos solucionar las cosas en las que no confiamos para que sean confiables de nuevo? Y luego mi favorito, nunca confíes en una prueba que nunca has visto fallar. Entonces, cuando empezamos a desglosar cómo miramos nuestras pruebas y cosas así, si nunca ha fallado, ¿cuánto valor está agregando esa prueba ? Podría estar agregando mucho valor porque es importante y la gente sabe que no debe romperlo. Pero si cambias algo y la prueba no falla, solo está desperdiciando tu CI. Está desperdiciando tu tiempo del desarrollador. Va a crear momentos en los que se distraigan. Sé que si dejo mi teléfono al lado de mi escritorio mientras estoy trabajando, trabajo desde casa, y tengo una tarea de larga duración, hay una posibilidad de que levante mi teléfono, juegue un juego, vaya a las redes sociales, cosas así. Lo cual no es necesariamente el uso más productivo de mi tiempo. Y entonces, vamos a dejarlo ahí. Y luego, con suerte, podemos comenzar a sumergirnos en algunas de las pruebas y cómo nos acercamos a estas cosas. Como dije, voy a usar Nightwatch. Me gusta Nightwatch. Hace todo lo que necesito. También me da los beneficios de tener una sola línea de comandos para trabajar con, en lugar de tener que averiguar cómo ejecutar esto, cómo ejecutar eso. Podemos partir de ahí. Entonces, David, ¿puedo volver a la diapositiva anterior? Me gustaría agregar algo. Porque cuando comencé a trabajar con pruebas automatizadas, la persona que me estaba entrenando, una de las cosas que me enseñó fue que cuando construyes tu tarea, te aseguras de que falla. Lo obligas a fallar para que sepas que cuando debería fallar, fallará. Entonces, ¿considerarías eso una mejor práctica al escribir pruebas automatizadas? Y otra cosa que parece muy relacionado con esta diapositiva es ¿ayudaría TDD a confiar más en tus trajes de prueba? Sí. Entonces, voy a comenzar desde la segunda parte de tu pregunta y trabajaré hacia atrás, si eso está bien. Sí, perfecto. Soy un gran defensor de TDD. He estado haciendo TDD durante años. La mayor parte es que me da un punto de partida. Creo que mucha gente malinterpreta TDD porque la gente dice, oh, puedes ¿escribes una prueba? No sabes lo que vas a desarrollar. Es como, bueno, sé por dónde empezar mi

TDD y Confianza en las Pruebas

Short description:

Comienza con TDD para una red de seguridad. Confía en las pruebas que han fallado. Evita los falsos positivos. Usa la herramienta adecuada para el trabajo. Confía en las herramientas utilizadas en las pruebas de extremo a extremo. Configura Nightwatch y utiliza el navegador que tus usuarios están utilizando.

va a ser la salida. Y entonces, empiezo desde ahí. Puede que no tenga la prueba más bonita o cosas así, pero la idea con TDD es que siempre vas, con esta entrada, debería tener esta salida, ¿verdad? Empieza por ahí. Incluso si eso se convierte en una prueba de integración. Creo que para aquellos que estuvieron en TestJS Summit, lo describí pensando en esto como, en lugar de pensar en unidad, integración, extremo a extremo, piensa en ello como pequeño, mediano, grande. Y entonces, la prueba mediana es esta posible prueba de integración donde estás pasando por diferentes cosas. Pero a veces necesitas esa forma de mirar en ello. Y entonces, soy un gran defensor de TDD porque está tomando el problema, asegurándome de que mi entrada es esta, y debería obtener una salida de eso. Mis pruebas no necesitan ser perfectas. Pueden ser realmente feas. Pueden ser lentas, lo que sea, ¿verdad? Pero tengo eso. Y entonces puedo ir, oh, ¿qué tal este escenario, y luego añadir eso en y, como, añadir una prueba para ello. Y entonces sé que tengo esto, como, lo que llamo una red de seguridad. Siempre tengo la red de seguridad, y luego puedo ir desde ahí. Y podría llegar al final de desarrollar esa característica. Y eliminar, como, tres cursos en mis pruebas, y sólo enviar uno, ¿verdad? Pero sé que he visto fallar ese desde el principio, y he trabajado mi camino a través de él. Cuando fui a Mozilla, una de las, porque esto, me uní a Mozilla en 2010. Así que, como, GitHub no era realmente una cosa. GitHub definitivamente no habría escalado a una gran empresa tecnológica como el proceso de desarrollo de Mozilla y CI, cosas así. Así que, lo que necesitabas hacer era, cuando estabas haciendo un parche, como, un cambio, adjuntarías un archivo a Bugzilla y dirías, aquí está mi cambio. Luego alguien lo revisaría. Luego alguien lo revisaría, como, revisaría a mano todo el asunto, porque no había una interfaz de usuario agradable o algo así. Mozilla tiene todas estas cosas ahora, ¿verdad? No había esta interfaz de usuario agradable, y lo harías. Pero lo que mucha gente haría entonces hacer, y especialmente en ese momento, porque yo era, como, un líder técnico, otro líder técnico revisaría mi código. Y lo que siempre solía hacer, un encantador alemán, era que cambiaría todas las ciertas, como, entradas, sólo para ver que mientras estaba pasando por ciertas cosas, sabía que no encontraría lo que necesitaba, y la prueba empezaría a fallar, y luego lo cambiaría de nuevo, y luego se aseguraría de que la prueba estaba haciendo lo que era. Y entonces, sí, he visto a gente hacer esa primera cosa de cambiar cosas sólo para ver la prueba fallar. Pero creo que es realmente importante que tengamos pruebas en las que confiamos, y yo no confío en una prueba que nunca he visto fallar. Pero al mismo tiempo, en un equipo, si me dijeras, he visto eso fallar, confío en esa prueba, ¿verdad? Como, no es que yo personalmente necesite verlo fallar, pero yo como equipo, he visto esa prueba fallar. Sí, y si pudiera añadir un último pensamiento aquí, es, porque he estado en situaciones donde si no ves la prueba fallar, podrías tener lo que se llama también un falso positivo, ¿verdad? Una prueba que está pasando cuando en realidad debería estar fallando, pero ves, como, el resultado de tu suite de pruebas es todo verde, piensas que debería ser todo bien para desplegar a un nuevo entorno como producción, y luego empujas a producción y las cosas se rompen, y no sabes por qué, porque tu suite de pruebas era todo verde. Así que, creo que una de las cosas importantes de verlas fallar es que también no introduces falsos positivos, porque la gente habla de falsos negativos, los que están fallando cuando no deberían, pero no hablan tanto de los que están pasando cuando deberían estar fallando en su lugar. Sí, estoy totalmente de acuerdo con eso. Y entonces, esto es por qué, al menos en mi experiencia, mucha gente se centra en un tipo específico de prueba o una herramienta específica. La herramienta debería ser la adecuada para el trabajo, y luego ir desde allí, y luego ver si esa cosa pasa, falla a medida que avanzamos. Y entonces, esto es por qué, para mí, mientras voy a mostrarles Nightwatch, mostrarles todo Nightwatch, todo lo que pueden hacer aquí debería ser traducible a todas las demás herramientas que hay, porque se trata sólo de la mentalidad de nunca confiar en una prueba que nunca has visto fallar, y nunca tener que esperar a un ordenador. Si entramos en esos pensamientos, como esos pensamientos de alto nivel, entonces todo lo demás esperemos que simplemente tenga sentido a medida que lo desglosamos. Y creo que es importante hacer eso. El otro que creo que es importante, y esto es un poco controvertido, pero creo los últimos cambios de Apple, creo que van a hacerlo más importante en el futuro, es que a medida que entramos en las pruebas de extremo a extremo, deberíamos confiar en las herramientas que usamos para ser lo que nuestros usuarios están esperando. Y entonces, con ese uno, no tengo una jerga elegante para ese uno, pero ese uno es, como, usa el navegador. Como, si estás haciendo una prueba de extremo a extremo, usa el navegador que tus usuarios están usando, porque entonces puedes ver cómo están fallando las cosas. La principal razón por la que salió en la última semana, y espero escribir un blog sobre ello esta semana, son los cambios de Apple en la UE donde puedes instalar navegadores de terceros. Así que, podrías instalar Chrome, y será Chrome, no Chrome con un backend de Safari. En realidad usará el backend de Chrome. Digo, con Firefox, usará el backend de Firefox. Y es importante que creo cuando pensamos acerca de estas cosas, porque, como, no puedes simplemente confiar en que WebKit estará haciendo lo mismo en el camino. Pero podemos entrar en cada uno de esos a medida que avanzamos. Así que, en este caso, vamos a configurar Nightwatch. Te guiaré a través de la configuración de Nightwatch. Para mí, porque trabajé en herramientas y desarrollos, que, como, si alguna vez has trabajado en Google, ese tipo de equipo o área se llamaría productivity de ingeniería. Hay varios términos alrededor de ello. Pero son personas que piensan en el DX y la velocidad y las cosas de cómo estás mirando los problemas. Y entonces, cuando hemos estado trabajando en Nightwatch, hemos creado un

Configuración de Nightwatch para Pruebas en Móviles

Short description:

Muestra el proceso de configuración para Nightwatch. Selecciona las pruebas de aplicaciones móviles para un entorno móvil. Prueba contra simuladores de iOS y Android. Prefiere JavaScript sobre TypeScript. Elige React para las pruebas de componentes. Selecciona Safari y Firefox para los navegadores. Almacena las pruebas en localhost o utiliza un servicio como BrowserStack. Recopila métricas anónimas para el seguimiento de errores. Configura emuladores móviles y dependencias. Aprueba la automatización de Safari a través de sudo.

herramienta init. Playwright tiene una, WebDriver.io tiene una. Probablemente, Cypress tiene una. Nunca me he metido mucho en la configuración de Cypress. Pero en este caso, voy a mostrarles por qué, en este caso, esta va a ser la única parte de codificación en vivo que verán hoy. Así que, literalmente no puedo escribir cuando la gente está mirando. De hecho, vamos a cancelar eso. Y entonces, en este caso, sólo voy a hacer... Así que, lo va a poner en ese directorio. De esta manera espero que las cosas no sean tan lentas. Creo que la parte más importante, voy a suponer que todavía pueden ver mi pantalla es que, como en la parte inferior, tenemos cosas como pruebas de extremo a extremo, tenemos pruebas de componentes, que creo que es realmente importante y lo vamos a hacer hoy. Y luego vamos a hacer... Voy a seleccionar pruebas de aplicaciones móviles. No es obvio y creo que cambiaremos la pregunta de la aplicación un poco. Pero eso configurará un entorno móvil para que podamos ejecutar nuestras pruebas contra él. Y entonces, esas también pueden ser pruebas web. Así que, en mi caso, estoy en una Mac. Así que, podré probar contra simuladores de iOS, pero también puedo ejecutarlo contra simuladores de Android y lo configurará para nosotros, porque eso es realmente bastante difícil de hacer. No sé cuántos de ustedes pasarán mucho tiempo en móviles, pero me han llevado a creer que después del año de Linux, el móvil será el futuro o tal vez al revés. Veremos. Bien. Y entonces, seleccionamos los tres. Prefiero hacer las cosas en JavaScript en lugar de TypeScript. Sé que TypeScript te da todo esto apoyo extra cuando haces cosas y Nightwatch funciona con ambos, pero prefiero JavaScript. Elegiré React, pero podemos, esto es para pruebas de componentes. Y podemos hacer Safari, Firefox. Seleccionamos ambos. Y ahí es donde almacenamos nuestras pruebas. Eso puede ser donde están las cosas. En este caso, voy a seleccionar localhost. Pero podría ser como, así que, si quieres ejecutar esto en un servicio que te da acceso a teléfonos móviles, así que, BrowserStack tiene esto. Hay otras empresas que lo hacen en el espacio. Puedes seleccionar eso. Sólo haré localhost por ahora. Pero te mostraré lo que pasa en el camino. Y entonces, si usas Nightwatch, recogemos métricas anónimas. Nunca es acerca de lo que estás probando. Es sólo para ver cuántos errores te encuentras y con qué frecuencia ejecutas. Esa es la data. Mi experiencia en Mozilla me ha ayudado a limitar la cantidad de data que recogemos, pero es útil para nosotros como un grupo de código abierto. Otra cosa agradable es, es que va a seguir adelante y configurar todo. Una de las cosas que hice para móviles, y lo verán en un segundo, es que también configurará todos los emuladores móviles. Configurará nuestras dependencias. Eso es algo bueno porque es una masterclass. Tenemos el tiempo extra. Debería estar ya hecho. Así que, saltar. Así que, esto es, si quieres usar Safari, automatizar Safari, necesitas hacer algunas aprobaciones a través de

Configuración del Entorno Android y Pirámide de Pruebas

Short description:

Configura el entorno Android utilizando el emulador. Descarga la aplicación de muestra y configura el entorno móvil. Ejecuta pruebas en móvil. Nightwatch proporciona directorio, ejemplos y pruebas de plantilla. Sigue la pirámide de pruebas. Más pruebas unitarias, menos pruebas de servicio, aún menos pruebas de UI. La inestabilidad aumenta con la integración. Evita depender únicamente de las pruebas de UI debido a su lentitud.

sudo. Ya lo he hecho. Debería funcionar. Pero permite que Safari sea automatizado. Ahora está configurando las cosas de Android. Descargamos una aplicación de muestra. Y así, cuando Nightwatch configura todo, también configura todos los entornos de muestra para ti. Esta es una pregunta. Creo que el mío es diferente. Sí, es diferente. Sí. Ese parece un buen lugar. No tengo un Android, así que usaremos el emulador. Esperemos que en un momento, deberías ver el emulador iniciar. Obviamente, porque tengo dos pantallas, lo ha puesto en la pantalla equivocada. Ahora, en este caso, porque seleccioné Firefox, porque todavía me importa Firefox, sabe que el emulador no tiene Firefox. ¿Quiero configurarlo? Sí. Así que irá a descargar el APK de un servidor de Mozilla, y así de simple, vamos a tener todo nuestro entorno móvil configurado para nosotros. Y guarda el estado, lo borra todo, y luego te dice cómo ejecutar todo. Porque aquí es donde los dioses de la demo me odiarán, obviamente. Entonces, sí, podemos... Normalmente, eso debería haber funcionado. Pero volvemos y probamos la versión de Android. Esperemos que, iniciando Chrome, cargando el navegador. Entonces, testing en móvil no es mucho más difícil. Va a fallar ahora, porque recuerdo testing antes, y cambiaron algo en el sitio web. Pero podemos ir. Entonces, así. Podemos ejecutar cosas en móvil, y así configurar todo está ahí para nosotros. No necesitamos preocuparnos. Podemos seguir adelante y hacer todo. Entonces, ahora tenemos todo un entorno. En este caso, está todo ahí. Si usas Nightwatch, una de las cosas que realmente aprecio de Nightwatch es que te da un directorio, te da ejemplos, te dice cómo hacer accessibility testing. Llegaremos a algo de eso en un minuto, y cómo desglosar las cosas, las aplicaciones. E incluso te da dos pruebas de plantilla, para que puedas simplemente, como, copiarlas, te dice qué actualizar. Entonces, en este caso, una prueba de inicio de sesión, porque todos necesitan un inicio de sesión hoy en día, ¿no es así? Entonces, tengo este, y posiblemente volvamos a él en un minuto. Pero lo que quiero hacer antes de que empecemos a sumergirnos en las pruebas es que quiero volver a, porque esto es como el quid de todo, es lo que veo cuando hablo con la gente en diferentes cosas de, como, cómo la gente mira las pruebas y qué deberían estar haciendo. Y así, todos hemos visto la pirámide de testing. Sabemos que debería haber mucho más pruebas unitarias que pruebas de servicio que pruebas de UI. Entonces, a lo que dije antes, deberías tener más pruebas pequeñas, menos pruebas medianas, y aún menos pruebas de UI. Las pruebas de UI deberían estar al final. Y la mayor razón para esto es que a medida que subes, cuanto más integración, más integración haya, más inestable se volverá. Es una garantía. Ahora, si miras, como, cómo Google ejecuta sus pruebas, saben que una cierta cantidad de pruebas van a ser inestables con cada push. Y para ellos, simplemente, como, bueno, siempre que ese número no esté subiendo, está bien. ¿Verdad? Y tienen miles y miles y millones de pruebas, ¿verdad? Y no es solo, como, pruebas de UI. Es todo. Pero el principal punto es, cuanto más integración haya, mayor será el potencial de inestabilidad. Y lo que he visto en mi experiencia es que obtendrás un montón de estados que dirán, bueno, simplemente hagamos todo con la prueba de UI. Será suficientemente bueno. No podemos hacer eso porque son lentas. No podemos estar esperando 24 horas. No podemos estar esperando en computadoras donde los humanos,

Explorando Nightwatch y Configurando Entornos

Short description:

Explora proyectos de ejemplo en Nightwatch y su configuración. Los plugins extienden la funcionalidad de Nightwatch. Configura diferentes entornos para pruebas con Firefox, Chrome y Android.

las computadoras deberían estar esperándonos. ¿Verdad? Y entonces, desde allí, vamos a desglosarlo, mirar nuestras pruebas unitarias, y voy a hacerlo, porque tengo configurado Nightwatch, tengo un proyecto de ejemplo con el que puedes jugar. He hecho cambios, pero compartiré el fork del repositorio en el que estoy trabajando. Pero si quieres echarle un vistazo, descargarlo, lo pondré en el chat. Así que, hagamos eso primero. Ya no necesito esto. Entonces, Nightwatch tiene una community, organización, proyectos de usuarios a los que cualquiera puede enviar, cosas así. Tengo estos dos, porque quería proyectos que tuvieran pruebas de componentes testing. Así que, tenemos ese, y tenemos este. Voy a, extrañamente, voy a hacer cosas en los pocos proyectos mucho más. Principalmente porque sé que todo funciona con React, y me gusta trabajar con proyectos menos conocidos, cuando es posible en estos casos. Entonces, React se lleva la mayor parte del mundo, pero podemos verlo.

Una de las cosas cuando configuré Nightwatch es que Nightwatch, y aquí es donde la simplificación de las cosas se vuelve realmente importante. Hagamos la suposición de que puedes ver eso, si no, solo avísame. Tiene esta configuración, y, como, hay pequeños bits y piezas aquí que no necesitas preocuparte demasiado, pero te mostraré en otro proyecto, en el tipo de proyecto de vista de tareas pendientes, donde he hecho cambios, qué serían estos. Pero, en su mayor parte, tenemos plugins. Estas son cosas que de alguna manera extienden Nightwatch. Entonces, webdriver tiene plugins, Cypress tiene plugins. Como, simplemente te permite tener el espacio, y luego construir todo. Y, según lo necesites, y habrá diferentes bits de información allí. Tenemos, ya sabes, configuraciones de prueba, estas, como por defecto, es un entorno. Es el entorno por defecto, entonces, si solo vas a npx nightwatch, ejecutará todo de acuerdo a los valores por defecto. Si quiero ejecutar Safari, solo podría decir npx nightwatch-e, y luego Safari, y se iniciará Safari. Lo mismo con Firefox, Chrome, Android,

Pruebas unitarias con Nightwatch y estilos de JavaScript

Short description:

Ejecuta pruebas unitarias sin la necesidad de iniciar algo. Utiliza diferentes estilos de JavaScript para las pruebas.

así que te gustaría si hay diferentes cosas. Entonces, en este caso, necesitamos poder decirle a Firefox dónde, qué hacer, qué iniciar, necesitamos decirle a Chrome, como, son estas cosas. Y entonces, esto, podemos partir de ahí. Correcto, así que sigue y sigue. Entonces, si solo reduzco eso, volvemos aquí, vamos a crear una prueba unitaria, en este caso. Es solo un nuevo entorno, lo siento. Y vamos a construir eso. Ahora, esto es una de las cosas, razones por las que, como, desde mi lado, por qué prefiero proyectos como este, es que con todo lo que hacemos, solo va a ser npx nightwatch, y luego vamos a cambiar algo al final sobre cómo queremos hacerlo. Entonces, tengo que encontrar el correcto. Aquí estamos. Correcto, eso. Correcto, está bien. Y entonces, puede crear una prueba unitaria, por ejemplo. Ahora, las pruebas unitarias, en este caso, nunca, nunca, nunca deberían necesitar iniciar algo. Y deberían poder desglosarlo bastante rápido y ver algo que está ahí. Entonces, en este caso, he hecho una especie de super simple, donde solo son estas dos cadenas iguales entre sí. Solo para tipo de aclaración, verás una mezcla de diferentes estilos de JavaScript, principalmente porque, como, la gente está escribiendo su JavaScript de diferentes maneras. Podría parecer un poco desordenado, pero en realidad, tenía la intención de hacerlo de esta manera, para que puedas ver lo que estaba pasando. Y puedes ver, como, tu estilo de hacer las cosas. Excepto para TypeScript, no vi que hubiera demasiada diferencia. Pero puedes hacer CommonJS TypeScript o, oh, mi cerebro todavía está trabajando. Solo módulo normal.

Configuración de pruebas unitarias con variables de entorno

Short description:

Utilice variables de entorno para evitar almacenar datos sensibles en el repositorio. Configure y ejecute pruebas unitarias simples con facilidad, asegurando la legibilidad y el fácil mantenimiento.

Entonces, puedes hacerlo todo. La configuración es un archivo .js, o un archivo ts, o un archivo cjs, porque puedes, es ejecutable. Entonces, si hay un proceso data en el que necesitamos entrar, por ejemplo, si estás trabajando con un tercero y necesitas contraseñas, nunca es bueno poner contraseñas en tu repositorio nunca. Debería haber diferentes formas de incorporar esos data en tus pruebas. Y entonces, las variables de entorno son normalmente la forma más fácil. Y con las variables de entorno, puedes apagar cosas más rápido que leyendo desde un archivo, especialmente si el sistema está bajo mucha presión. Entonces, en este caso, tenemos una prueba unitaria simple. Podemos, esto es donde va a parecer un poco feo, disculpas. Deberíamos ser capaces de simplemente ejecutar una especie de prueba simple con todo. Vamos a cambiar nuestro entorno. Entonces, el entorno, como, es solo donde necesita ejecutarse. ¿Lo llamamos prueba unitaria? Pruebas unitarias. Eso es lo que, lo siento. Prueba. Y podemos obtener algo simple. En este caso, olvidé establecer las carpetas de origen. Puedes establecer, como, tengo filtros, pero olvidé establecer las carpetas de origen. Pero eso es bastante fácil. Y en su mayoría, al crear estas pruebas, básicamente deberías mirar el problema de, como, si me voy de vacaciones y vuelvo, ¿todavía recordaré cómo ejecutar mis pruebas? Entonces, algunas personas ponen esto en el package.json. Perfectamente aceptable si estás usando una herramienta de compilación, como, en realidad, hay tantas en JavaScript hoy en día. Ponlo allí y entonces solo necesitas recordar eso. Y entonces, es realmente agradable que en este caso para mí, solo necesito recordar

Pruebas y Simulación de API con Nightwatch

Short description:

Aprenda cómo usar Nightwatch para pruebas y simulación de API, y la importancia de centrarse en menos pruebas de extremo a extremo. Explore pruebas unitarias, configuración de CI y creación de un servidor simulado. Comprenda el equilibrio entre la simulación y la alineación de datos del mundo real.

Nightwatch en el entorno. Entonces, desde aquí, vamos a subir la pirámide. Y en este caso, iba a hacer un montón de diapositivas, e hice algunas. Pero voy a volver a ellas porque creo que en realidad es más fácil trabajar desde aquí. La parte principal aquí para la forma en que Nightwatch funciona es que utiliza supertest. Estoy seguro de que algunos de ustedes ya están usando supertest. Pero en su mayoría, tiene su propia API testing, su propio servidor de simulación. Entonces, puedes hacer esto. Mostraré un ejemplo de las pruebas. E incluso podemos ver cómo escribir una prueba. No tengo la configuración en el servidor porque pensé que podría ser interesante ver qué podrían hacer las personas, o si tenían preguntas específicas. Entonces, en este caso, tenemos cómo configurarlo, añadiendo el plugin. Entonces, si vuelvo a VS code, solo necesitamos añadir en API testing. Solo lo configuraremos. Obviamente, no lo guardé. Solo voy a comprobar que lo hice instalarlo. Entonces, añádelo. Porque Nightwatch comenzó como una herramienta Selenium, ha trabajado su camino de regreso a unit testing. Necesitamos decir, no inicie WebDriver, porque no es necesario. No todo debería estar en una prueba de extremo a extremo. De hecho, acabo de recordar a Simon Stewart, el creador de WebDriver, famosamente dijo que solo deberías escribir una prueba de extremo a extremo. Su principal razón para eso fue, si te dijera que escribieras 10, te centrarías en las 10, pero si te dijera que escribieras una, te centrarías en asegurarte de que podrías escribir una, y si tuvieras otra, simplemente añadirías otra. Pero esa primera sería la mejor. Añade la mejor cantidad de valor. Muy bien. Genial. Hemos llegado a una hora. Solo quiero comprobar, antes de continuar, ¿las personas quieren necesitar un descanso biológico o algo así? Genial. Continuaremos con las pruebas de API pero pruebas, y vamos a entrar aquí. Y en su mayoría, iba a ver sobre la creación de una prueba que podríamos simplemente ejecutar. Entonces, todos nuestros ejemplos están destinados a hacer esto, pero la idea es que deberíamos intentar desglosar y hacer menos pruebas de extremo a extremo. Entonces, aquí tenemos una prueba de API, aquí tenemos una prueba de API, y deberíamos poder ejecutarla bastante rápido. Tengo la memoria de un pez. Lo veremos en un minuto. Ignorando esta parte, es porque simplemente añadiré eso. Eso es mejor. Y ahora que eso está funcionando, y siempre, siempre haz eso. También podemos echar un vistazo. Porque sé que algunas empresas les gusta cuando las personas crean informes, podemos echar un vistazo a nuestras pruebas de API. Y volveremos a esto en un minuto. Pero esto es, tenemos nuestras pruebas unitarias. Si estuviéramos configurando un CI, esas se ejecutarían en un corredor independiente, tenemos nuestras pruebas de API. Si estuviéramos creando eso, lo haríamos y luego construiríamos eso. Si volvemos aquí, no lo voy a hacer, pero si las personas querían ver un ejemplo, tenemos cómo hacer publicaciones, que es bastante útil, pruebas de API, y si necesitabas simular ciertas partes de tu suite de pruebas, deberías poder crear un servidor simulado. Y luego solo comprobar. Y entonces, la simulación puede ser realmente útil para acelerar tus pruebas porque queremos ese bucle de retroalimentación rápido, pero hay un inconveniente de que si algo no está configurado al 100% podemos, los datos simulados y los datos del mundo real nunca se alinean. Y eso es donde antes, la gente hablaba de falsos positivos, porque tus datos simulados son correctos. Bueno, son incorrectos, pero la prueba está pasando. Entonces, siempre es un equilibrio al mirar estas cosas y puedes crear. Entonces, yo,

Gestión de la Complejidad en el Diseño de Software para Pruebas

Short description:

Explore el equilibrio entre las necesidades de diferentes personas y encontrar el nivel adecuado de complejidad en el diseño de software para pruebas. Discuta el desafío de gestionar el número de archivos y directorios en la configuración de Nightwatch y el impacto de la complejidad del proyecto.

hay muchas cosas diferentes que puedes hacer con él. Construye esto según lo necesites. Puedo entrar en ello con un poco más de detalle si la gente quiere, pero creo que diferentes cosas pueden, como diferentes personas quieren cosas diferentes. Y entonces, simplemente, se trata de encontrar ese equilibrio correcto para lo que necesitas. David, ¿te importaría si te interrumpo y te hago una pregunta? Por supuesto. Adelante. Me impresionó bastante la cantidad de archivos y directorios que se crean cuando configuras night to night watch. Y digo eso porque estoy creando una masterclass que trata sobre el diseño de pruebas. Y cuando pienso en eso, el diseño de software en general, lo veo desde el punto de vista de la complejidad, lo que significa que cuanto más complejo es el proyecto,

Herramientas, Complejidad y Reporte de Pruebas

Short description:

Discute el equilibrio de herramientas y valores predeterminados en Nightwatch y Cypress, y la importancia de comenzar con la menor complejidad en el diseño de software. Considera el valor de los informes de pruebas y la preferencia por los resultados de pruebas verdes sobre los informes extensos.

cuanto más difícil será para mí o para otros trabajar en él. Esto es algo que me gusta mucho en Cypress, por ejemplo, y no estoy comparando herramientas o algo así, pero Cypress, por ejemplo, el archivo de configuración es muy pequeño porque no necesitas saber sobre los valores predeterminados, simplemente están ahí. La cantidad de archivos y directorios que se crean también son pequeños y evolucionas con tus necesidades. Y cuando miré la cantidad de cosas que Nightwatch creó, a primera vista, me sentí un poco asustado. Así que quería explorar, no asustado en el sentido de que hay tanto que podría tener que mirar, o hay cosas que noté, como objetos de página, directorio, utilidades, y ese tipo de cosas que podría necesitar en el futuro, pero que podría no necesitar cuando estoy comenzando un proyecto. Así que quería saber si hay una forma de, al configurarlo, decir, no quiero esto y aquello. Y la otra cosa, que es lo más importante que quería escuchar de ti es ¿cuáles son tus pensamientos sobre construir software con la menor complejidad posible y agregar complejidad cuando sea necesario, pero siempre presionando para eliminar la complejidad? Y si no fui claro, haz... Sí, lo siento, estoy pensando en ello. Entonces, para tu primera cosa, no, no hay forma de eliminar, no, detener la creación de esos archivos. Lo que sí decimos a la gente con eso, y en su mayor parte, es como, es un equilibrio, y aprecio plenamente que a veces no lo hacemos bien, es que con ese equilibrio, es cómo damos a la gente las herramientas que necesitan, versus la gente que mira y dice, genial, ahora necesito agregar objetos de página, pero no tengo idea de dónde se sientan. Y no estoy diciendo que lo hagamos bien, lo describo como una forma de tratar de ayudar a la gente a través de lo que llamo el proceso, el principio de la menor sorpresa. Correcto. Y así quiero dar a la gente la menor cantidad de sorpresas con las cosas. Así que podría ser, en nuestro caso, en el caso de Nightwatch, nos hemos inclinado de una manera, pero podría decir en el mismo aliento que como, digamos, Cypress, que te da muy poco está en la dirección equivocada, potencialmente. Y hay podría haber un término medio para ambos tipo de cosas, donde es un caso de, oye, no me des los archivos de prueba, porque no los necesito, sé lo que estoy haciendo. Pero sí, siempre, como cuando hemos hablado de esto en el pasado, siempre ha sido como, es porque es, si miras, déjame cargar ese archivo. Quiero decir, en Cypress, aunque este archivo de configuración es muy pequeño, si quieres, puedes ver todos los valores predeterminados en la aplicación de ejecución de Cypress. Pero si solo quieres empezar, puedes empezar con el mínimo indispensable y agregar según lo necesites, y tienes una referencia de dónde buscarlo. Sí. Entonces, para nosotros, en su mayor parte con Nightwatch, si no sabías nada y simplemente ejecutaste Nightwatch y nunca miraste en este archivo, eso también estaría bien. ¿Correcto? Y así estoy tratando de mostrar que, como, en este caso, tenemos el valor predeterminado, el valor predeterminado va a cargar Chrome y en realidad voy a hacer algo en un minuto. Donde, si borro Chrome de mi máquina, entonces también irá a buscarlo e instalarlo, por eso estoy comenzando con las cosas de prueba de API para sacar eso del camino, porque la siguiente parte se vuelve un poco más compleja. Principalmente porque es como todas estas cosas geniales que ahora que sabes que están ahí, puedes olvidarte de ellas, ¿verdad? Tipo de cosa. Y así en este caso, pero los ejemplos, queremos dar a la gente formas de hacerlo, pero si fueras a, porque nada está en el directorio de pruebas, pero todo está en el directorio de Nightwatch, así que ahora puedes copiar lo que necesitas de un lado a otro. Y eso es lo que alentamos. Y incluso nuestra documentación intenta explicar eso a la gente, pero al mismo tiempo, es una línea fina.

Entonces, tengo tu segunda pregunta. ¿Cuál era tu segunda pregunta? Estaba más relacionada con el diseño de software para pruebas. Como el enfoque de comenzar con la menor complejidad y agregar según sea necesario. Pero hay otras cosas que me vinieron a la mente también que me encantaría escuchar de ti también. Ya que nos mostraste un informe de prueba HTML, hice un en vivo en mi YouTube una vez hablando de eso. No uso este tipo de informes porque estoy bien con el informe de línea de comandos que ya tengo, la traza de pila, con los registros y todo. Y lo que valoro en un script de prueba es que todos sean verdes. Entonces, si todos son verdes, no hay necesidad de un informe. Y lo que veo a veces es gente preguntándome, ¿cómo hago para configurar un informe de prueba para este marco o para este otro marco? Al final, ellos están simplemente haciendo eso porque la gerencia quiere ver un informe. Pero lo que creo que la gerencia debería estar buscando es que todas las pruebas están pasando, lo cual no requeriría un informe al final si es todo verde. Sí. Entonces, ese problema, es único. Personalmente, soy un poco como tú. Dice que pasó. Incluso tiene chispas. Eso debería ser suficiente. Y si vuelvo a, digamos, Treeherder, Treeherder solo busco verde. Si mi push es todo verde, bien. Mi gerencia no se preocupa cuando estaba en MSL. Siempre que todo sea verde y no esté rompiendo la construcción, porque si rompo la construcción, es... Dependiendo de la gravedad de cuán mal rompí la construcción, podría ser un caso de 2000 horas de computación de CI que necesitan correr de nuevo. Y en ese caso, fue malo. Lo que he visto mucho... Y esto es preferencia personal. No creo que necesitemos herramientas como Cucumber y cosas así, porque creo que los nombres de prueba significativos

Modularidad y Composición en el Diseño de Software

Short description:

Discute la importancia de la modularidad y la composición en el diseño de software, así como la capacidad de realizar cambios seguros en sistemas complejos. Destaca los beneficios de componer pequeños módulos y escalar el CI.

o aserciones significativas son más importantes que una especie de informe de prueba. Entonces, si solo quieres mirar, en mi testing de API, está haciendo esto. Genial. Puedo ver por los nombres de las pruebas. Debería ser capaz de entenderlo. Solía meterme en muchos problemas en Mozilla, porque los nombres de mis métodos de prueba serían como nombres de 40, 50 caracteres, porque era una frase. Diría, debería hacer esto, ¿verdad? Debería pasar por esto, luego hacer esto. Y lo haría. Y la gente decía, oh, no necesitas que sea tan largo. Yo decía, sí lo necesito. Porque entonces puedo leer cuando veo la salida de lo que está pasando, lo que no está pasando, lo que debería estar haciendo, no haciendo. Y si necesito ir a arreglar una prueba, puedo decir, debería estar haciendo esto. Y la parte más importante es que debería ser capaz de, con confianza, hacer cambios. Entonces, a tu punto sobre cuánto más complejo es el sistema, más difícil es hacer cualquier cosa. Sí, definitivamente. Pero eso no significa que no puedas tener sistemas complejos construidos de manera muy simplista, ¿verdad? Deberías ser capaz de tener todos estos modules, y cuando los conecto juntos, tener este gran sistema. Entonces, un navegador es un ejemplo perfecto aquí, ¿verdad? Sí. Creo que la modularidad es una de las claves, ¿verdad? Si tienes modules muy pequeños que puedes componer software con ellos, entonces está bien. Sí. Sí. Siempre, hay una, como, si vas a la orientación a objetos, hay esta frase, composición sobre herencia, ¿verdad? Deberías ser capaz de componer tus objetos juntos para construir lo que necesitas. Java es brillante, que es como, odio Java, pero cuando miro cómo hace Java, es como, en realidad, eso es bastante hermoso, cómo puedes componer cosas y se ve increíble. La gente mezcla y combina mixins y cosas así en Python y Ruby. No soy un gran fan de los mixins, a pesar de que soy una persona importante de Python y JavaScript. Pero el punto es que deberías ser capaz de componer todo, y luego, mientras piensas en cómo lo compones, puedes pensar en cómo puedes escalar tu CI, porque tú, como, esto es esto, aquí están las unidades de API, API, y vamos a

Complejidad de los Navegadores y Pruebas de Componentes

Short description:

Discute la importancia de entender la complejidad de un navegador y la capacidad de hacer cambios examinando el directorio de nivel superior. Destaca el ejemplo de la creación del color 'Rebecca purple' en CSS y enfatiza la importancia de observar cómo se unen los módulos para construir, pilotar y probar cambios. Transición al siguiente tema de pruebas de componentes y la importancia de la resolución de problemas y la expansión de perspectivas.

ahora entramos en componentes, lo que sea, para esto, y lo construyes. Vas desde allí. Y creo que, me gusta, es una de las cosas que me gustaba de trabajar en un navegador es que el navegador es super complejo, pero si quería hacer un cambio, podía simplemente mirar el directorio, como mirar el nivel superior del repositorio e ir, vale, quiero hacer un cambio en cómo funciona el diseño, ¿verdad? Entonces, una de las cosas que hice de las que estoy realmente orgulloso fue poco después de que la hija de Eric Meyer's muriera, no sé si has oído hablar de Eric Meyer, es una especie de gurú de CSS, ha escrito muchas de las especificaciones de CSS, desafortunadamente, su hija murió de cáncer, y como una cosa que, la comunidad de CSS hizo fue que crearon un color para ella en todos los navegadores, porque su color favorito era el morado, y su nombre era Rebecca, y crearon Rebecca purple, así que si quieres echar un vistazo, y yo nunca había hecho diseño, nunca había hecho CSS, nunca había hecho nada, pero vi que esto estaba llegando, pensé, voy a hacerlo rápidamente, porque es de código abierto, e hice esos cambios. Y pude averiguarlo bastante rápido, simplemente mirando cómo se unen los módulos, cómo construirlo, pilotarlo y luego probarlo. Y ahí es donde miramos cómo creo que la gente siempre debería mirar estas cosas. Y a medida que entramos, porque voy a pasar a las pruebas de componentes, creo que es realmente importante para los siguientes pasos, ¿verdad? De nuevo, no son necesariamente las herramientas, sino cómo miras el problema, porque resolvemos el problema, y luego avanzamos

Pruebas de Componentes y Complejidad de la Interfaz de Usuario

Short description:

Discute el concepto de pruebas de componentes, que implica probar funcionalidades específicas de los componentes de React o View. Menciona las diversas herramientas disponibles para las pruebas de componentes, como Weeds, Svelte, Angular y Storybook. Enfatiza la importancia de probar interfaces de usuario complejas y destaca los desafíos con las pruebas de componentes web que crean un DOM de sombra.

hacia afuera y lo expande. Entonces, tengo API testing, y vamos a las pruebas de componentes. Entonces, este es un término importante. Es como que todos los principales frameworks lo soportan hoy en día, y la idea con las pruebas de componentes es que tomarás un componente de react, un componente de vista, componentes tomados, y solo pruebas esa única cosa que hace. Entonces, si voy aquí, y cierro esto, y cierro todo esto, para que realmente pueda ver lo que estoy haciendo. Puedo crear un, como, formulario de tareas pendientes, que es realmente simple. Crea una plantilla. ¿Qué debería pasar cuando hago esto? Y allí, podría tener elementos, como, cuando algo cambia. Puedo construir cada uno poco, y si necesito editar, como, creo un nuevo formulario para editar. Haz eso. En este caso, lo he hecho en vista. Pero si tomo react, y estos son proyectos que he compartido, y se basaron en lo que MDN estaba trabajando, como un ejemplo que el proyecto MDN estaba creando. Y entonces, si entro en componentes, puedo tener mi formulario. Entonces, si estás en react, así es como react lo mantendría unido, todos los elementos de la lista de tareas pendientes, e incluso puedes filtrar. Y si vamos, como, si no estás usando ninguno de esos, hay otras herramientas. Si puedo hacer que algo más funcione, donde, si digo, de nuevo, hay Weeds, hay Svelte, Angular, todos estos que mostraré, y hay un complemento de Storybook, si lo usas. Storybook es realmente grande, y eso, mucha gente lo usa. La gente ha oído hablar de Angular, Svelte, y así sucesivamente. Y entonces, hay diferentes formas de hacerlo. En su mayoría, puedes construir tus pruebas. Como dije, he sido, como, me gustan los desvalidos. Entonces, he tomado la vista uno, y he construido mis pruebas, y tenemos pruebas dependientes.

Y entonces, lo que esto va a hacer, estoy seguro de que si usas Cypress o cosas así, tiene cosas similares, montando componentes, comprobando que el componente está allí, y luego ejecutando la prueba. Entonces, esto es una de las cosas que iba a hacer. Entonces, no uso, soy un poco raro y maravilloso, es que tengo Chrome, mi máquina. Nunca lo uso, porque soy raro y prefiero Firefox. Si tuviera que decir, plataforma de lanzamiento, encuentra Chrome, no, no es la plataforma de lanzamiento lo que quiero. Quiero aplicaciones. Quiero Chrome, Google Chrome. Puedo moverlo a la papelera, y puedo ir, porque solo vamos a hacer cosas por separado, y solo voy a hacer npm run test, que va a hacer pruebas de componentes de Night Watch. Voy a cerrar eso, para que podamos tener una pantalla más grande. Entonces, esta línea es algo importante, en que lo que Selenium Manager es es una herramienta para comprobar que tienes todas tus dependencias cuando se trata de binarios. Entonces, esto podría ser lo que Selenium llama controladores, por lo que es una forma de conducir el navegador, pero también es una forma de asegurarse de que tienes un navegador. Entonces, parpadeó muy rápidamente allí, pero lo que hizo fue que fue y descargó Chrome para nosotros, y a diferencia de Cypress y Playwrights, es que está usando Google Chrome para testing, y entonces Google Chrome para testing es un navegador solo para testing que los Googlers han creado, y resuelve el problema de la actualización automática de Chrome, que solía romper Selenium, porque entonces Chrome driver y Chrome se desincronizarían. Entonces, si vuelvo a mi prueba, lo que puedo hacer, solo para demostrar que era Chrome, no ejecuta su propia tooling para eso, a diferencia de Cypress y Playwrights, pero usa todas las cosas que la gente necesita para ejecutar sus pruebas. Y entonces, pondré un enlace a cómo funciona esto en el proyecto Selenium, pero la parte principal es que si borré Firefox, o lo que generalmente sucede es que mucha gente no tiene Firefox en sus máquinas, si fueras a ejecutar esto, instalaría Firefox para ti, y descargaría el controlador Gecko, que es necesario, y entonces todo debería funcionar, lo cual es bastante genial, pero la parte más importante es que podemos asegurarnos de que todo está funcionando como se esperaba. Y entonces puedes construir todas tus pruebas de componentes. Entonces, este es para ti. Si voy a las pruebas de componentes, puedo construir varias cosas diferentes. Y sigue la misma convención que generalmente se necesita para cada una de las diferentes formas de hacer las cosas. Entonces, o lo montas, o simplemente creas un nuevo objeto de ese botón, y luego puedes hacerlo. Puedes hacer renderizado, puedes hacer cambios al renderizado como esperarías, porque cuando todo funciona, simplemente usas el usual juego para hacer cosas. Y entonces puedes tener tus pruebas, y, si quisieras, también podrías ver acerca de montar tu componente, ir desde allí. Pero tenemos eso. Entonces, con suerte, y la idea con las pruebas de componentes, para señalar antes la complejidad de los sistemas, es que las interfaces de usuario se están volviendo super complejas, y luego también los frameworks de front end no están pensando en cómo probarlo. Famosamente, si usas web components, si fueras a... Entonces, para aquellos que no saben qué es un componente web, es como un componente de React, pero está usando APIs nativas del navegador. Entonces, React y eso intentarán construir un componente web. Pero el problema es que si fueras a crear una sombra cerrada, como Shadow Root, porque un componente web crea una sombra debajo de él, muchas herramientas no pueden ver dentro de él. Selenium puede. Pero es bastante difícil.

Pruebas Visuales y de Accesibilidad en Nightwatch

Short description:

Explora el uso de las pruebas visuales en Nightwatch, que tiene su propio plugin de pruebas visuales. Discute las limitaciones del plugin y destaca herramientas alternativas como Percy y Applitools que proporcionan comentarios más precisos. Explica el proceso de configuración y ejecución de pruebas de regresión visual y enfatiza la importancia de las pruebas de accesibilidad en Nightwatch. Muestra cómo crear una prueba accesible y discute los beneficios de integrar las pruebas de accesibilidad, regresión visual y pruebas de UI dentro de un solo archivo.

Playwrights y herramientas similares, lo solucionan con su triple signo mayor que. Algo así como una frase. Para poder penetrar en él, para darte un buen dx para ello. El problema es que, y por qué personalmente no me gustan cosas así, es que no puedo copiarlo en las herramientas de desarrollo. Creo que es importante que cuando pensamos en cómo probar estas cosas, cómo nos sumergimos, como copiar cosas, ponerlas en las herramientas de desarrollo, ver con qué estamos trabajando. Porque a veces es un poco difícil de debug algunas de estas cosas. Pero espero que eso tenga sentido para la gente y puedas construir todo lo que necesitas. Lo siguiente que me gusta hacer con esto, especialmente con las pruebas de componentes, y animo a la gente a hacerlo, es que a la gente le gusta hacer pruebas visuales. Nightwatch viene con su propio plugin de pruebas visuales. Y te permite ejecutar tu prueba, hacer cosas como muchas herramientas en la máquina. Cuando se trata de esto, tiene muchas limitaciones. Y entonces aquí, puedes esperar tener una cierta cantidad de retroalimentación falsa en él. Como si algo está un par de caracteres, no caracteres, píxeles fuera, lo mostrará como un fallo. Donde si estuvieras usando algo como Percy, Applitools, cosas así, que han tomado esa información y la comparan con las imágenes base que tiene y permite tolerancias, puedes hacer cosas así.

Entonces deberías poder ejecutarlo. Y entonces lo que pasa con nuestras pruebas aquí es que he simplemente copiado una. Genial. Simplemente añade una API. Y entonces simplemente instalas el plugin, que es vrt. Si tienes un plugin, entonces es vrt. Así que simplemente lo instalas. Y desde aquí, y aquí es donde podemos, creo que es importante dividir las cosas horizontalmente cuando miramos cómo abordamos nuestras pruebas. En la primera ejecución, te dará un error rápido, pero luego crea una línea base para la imagen. Y puedes comparar cómo debería verse. Y entonces y luego las pruebas futuras no deberían fallar así. Bueno. Creo que eso es un bug interno, que debe estar haciendo cosquillas. Pero en su mayor parte es que tenemos una prueba vrt, una prueba de regresión visual, y simplemente nos aseguramos de que nuestra línea base... Así que la primera vez que lo ejecutas, creará la línea base. No dará error. Y luego la próxima vez, si algo cambia, debería empezar a dar errores. Lo que me gusta hacer en mis propios pequeños proyectos cuando se trata de estas cosas es que hago una prueba básica de vrt, pero también puedo hacer pruebas de accessibility. Y entonces la accessibility es un ciudadano de primera clase en Nightwatch, principalmente porque es importante hacerlo y no debería ser un obstáculo o ralentizar a la gente. La accessibility debería funcionar simplemente. Así que te mostraré cómo crear una prueba accesible aquí. Soy perezoso. Así que voy a copiar y pegar. Y entonces porque puedo decir que la accessibility es un ciudadano de primera clase, deberías poder buscarlo en mi sitio web. Y es simplemente una cuestión de inyectar eso en la página. Así que puedes probar tu dentro de un archivo. Puedes hacer accessibility, regresión visual, testing, y simplemente probar tu UI. Ignora el mensaje de error final cuando aparezca en un minuto. Bueno. Así que mi accessibility no es tan buena como me gustaría. Así que tengo que volver y cambiar eso. Y para, si quiero ver cómo se ve el informe, puedo. Puedo ver todo. Comprobé que todo funcionaba.

Mejores Prácticas para Pruebas de Regresión Visual

Short description:

Pregunta sobre las mejores prácticas para pruebas de regresión visual confiables, incluyendo pruebas de pequeños componentes, uso de datos determinísticos y enfoque en elementos específicos. Menciona los beneficios de herramientas secundarias como Percy y Applitools para manejar información no esencial. Enfatiza la importancia de las pruebas atómicas que son independientes y rápidas, y advierte contra las dependencias de pruebas. Discute el uso potencial de la inyección de JavaScript y la característica de fragmentación en Node.

Mi prueba de accessibility falló. Y eso funcionó. Y puedo ver. Mi prueba falló. De todos modos. Pero espero. ¿Puedo hacer una pregunta sobre las pruebas visuales? Sí. Que es si tienes alguna best practices para escribir pruebas de regresión visual confiables? Porque este es el tipo de pruebas que veo más o no más, pero muchos resultados negativos falsos. Aquellos que simplemente están fallando porque todavía estaba animando algo, o había un componente de carga todavía, o algo no se ha renderizado correctamente, o hay algunos datos dinámicos. Entonces, ¿tienes alguno, porque tengo escrito, he escrito una publicación de blog, desafortunadamente está en portugués. Puedo compartir de todos modos, entonces puedes traducir, pero hablo de muchas buenas prácticas que he usado en pruebas de regresión visual para hacerlas más determinísticas. Pero me encantaría escuchar si tienes alguna best practices tuya.

Entonces, para mí, no hagas pruebas de regresión visual contra toda la página. Encuentra pequeños componentes, por eso estoy haciendo esto en mi sección de pruebas de componentes. Así que pruébalo allí, porque trato de hacer esa parte tan determinística. La otra cosa con las pruebas de componentes, como con Nightwatch, puedes hacerlo con Cypress, todo es que puedes simular data. Y entonces si los data están cambiando, tu prueba de componentes probablemente no... las pruebas siempre deben ser, como deberían seguir cuando una prueba automatizada debe seguir tres pasos simples. Debería comenzar desde un lugar conocido, hacer una pequeña prueba, como una pequeña verificación y hacerlo bien, y luego volver al conocido lugar con el que comenzó. Y entonces si haces eso, todo debería ser esperanzadamente determinístico. Y luego al hacer la captura de pantalla, asegúrate de que esté en la cosa más pequeña que te importa. Si necesitas hacerlo en una cosa grande, que así sea. Pero entonces asegúrate de que el texto que está allí es siempre va a ser el mismo, y eso va a ser como lorem ipsum, ¿verdad? Algo que el texto siempre está allí, no data de una database que está cambiando. Pero aquí es donde la tooling secundaria, alguien como Percy, Applitools, cosas así, son mejores que ejecutar todo en tu máquina local, es que entonces puedes ir y comprobar, ellos dirán, oh, eso es una fecha. Podemos ignorar una fecha, por ejemplo, eso es un gran problema. Donde esto nunca va a ser tan, nunca va a preocuparse por ese tipo de información. Nunca se va a preocupar por ese tipo de información. Por mucho que me guste nuestra herramienta, nuestra herramienta solo te llevará, digamos, tres cuartos del camino. El camino que necesitas hacer es que necesitas una especie de otra parte. Y hay varias partes, obviamente mi empleador tiene una, pero hay varias partes que puedes intentar usar, y lo harías. Pero con todo, ¿verdad? Con tus pruebas unitarias, tus pruebas de extremo a extremo, cuanto más pequeñas sean, menos posibilidades habrá de que sean inestables.

Sí, me encanta que hayas puesto esto, porque esto es algo que no he añadido en mi publicación de blog, como tomar una captura de pantalla de la parte más pequeña. Las cosas que añadí allí es esperar a las visibilidades de algunos elementos que necesitan estar allí antes de tomar las capturas de pantalla. Lo mismo que dijiste, simulando los data de un backend, así que tienes tareas terminísticas. Las fechas son algo que dependiendo de cómo se construya la aplicación y dependiendo de la herramienta que utilices, por ejemplo, para Cypress, tienes un comando de lado, side.block que puedes congelar la fecha del navegador. Así que siempre estaría congelado en esa fecha específica. O a veces es algo otros data dinámicos que podrías ignorar con alguna cosa de CSS, como no te preocupes por ese selector de CSS. Hubo casos en el pasado donde tuve falsos negativos porque el cursor estaba parpadeando, así que desenfocaría la entrada antes de tomar la captura de pantalla. Y estas son algunas de mis mejores prácticas que uso al hacer este tipo de testing. Así que solo quería compartir. Eso es bueno. Así que no me gusta la característica de Cypress de bloquear las fechas porque en una prueba funcional eso es realmente útil. Si estaba haciendo una prueba de regresión visual y me importaba todo, y sabía que la fecha siempre iba a estar en un lugar determinado, podría simplemente inyectar JavaScript para cambiar la fecha para hacerla determinística solo para la prueba de regresión visual, pero solo impactaría esa prueba. No tendría cosas de funcionamiento más largo. En Cypress, puedes usar side.block para una tarea específica, cualquier cosa atrás, cualquier otra. Depende de cómo lo configures. Pensé que solo podías hacerlo como una característica de sesión completa. Pero sí, la parte más importante es que las pruebas deben ser atómicas, deben ser rápidas, y deben ser como, por atómicas, nunca deben depender de ninguna otra prueba. Y veo esto mucho, que la gente dice, oh, la prueba A inyectará data, y luego la prueba B dependerá de esos data inyectados. Es como, ¿qué pasa si solo querías ejecutar la prueba B? Oh, nunca pensé en eso. Pero es importante poder pensar en eso. La otra parte es que si yo fuera a hacer como

Mejores Prácticas para Pruebas de Extremo a Extremo

Short description:

Discute la importancia de las pruebas y las compilaciones deterministas. Enfatiza la necesidad de pruebas de extremo a extremo pequeñas y enfocadas y advierte contra la ejecución de un gran número de pruebas en la misma máquina. Destaca la importancia de usar datos simulados para garantizar pruebas deterministas. Menciona la experimentación de Google en esta área y la importancia de hacer las pruebas lo más pequeñas posible. Explica las consideraciones para las pruebas móviles, incluyendo las diferencias entre WebKit en dispositivos de escritorio y móviles.

en Node, creo que es Node 20, han añadido una característica llamada sharding. Y así si uso como Node para ejecutar mis pruebas directamente, y quiero hacer sharding, Nightwatch puede permitirte pasar argumentos de vuelta a Node. Y así puedes dividir tus pruebas. Playground tiene sharding, y a veces no sabes necesariamente dónde va a cortar ese shard, pero las pruebas deberían ser, como dices, deterministas. La compilación debería ser determinista. Todo debería ser determinista. Y debería ser rápido y debería tener todo lo que necesitamos. Así es. Y luego, hemos terminado con Visual, y luego hemos terminado. Vamos a pasar a las pruebas de extremo a extremo. Acabo de decir esto como una cosa. En su mayor parte, esperaba que esto fuera más una discusión en lugar de mostrar a la gente. Es que antes mencioné que, ya sabes, Simon Stewart dijo que solo deberías tener una prueba. También sé que eso no es factible. Pero cuando miro las pruebas de extremo a extremo, siempre deberían hacer algo realmente pequeño. He visto casos en los que la gente, especialmente en mi tiempo en Browserstack, nunca me di cuenta, nunca supe en Mozilla porque las pruebas tenían que ser atómicas. Pero la gente trataba de ejecutar, creaban mil pruebas, trataban de ejecutarlas todas en la misma máquina en paralelo, lo cual no es necesariamente factible. Porque hay limitaciones en cuántos navegadores puedes tener por núcleo. Y puedo entrar en eso en un minuto. Y luego, las pruebas sangrarían información de una prueba a otra. Y esa sangría podría causar muchos problemas aguas abajo porque los data no vuelven en el mismo sentido que los esperamos.

Y entonces, aquí es donde los data simulados son realmente importantes. Como, todas las herramientas de hoy en día te permiten simular solicitudes de red. Porque los navegadores tienen mejor tooling alrededor de eso internamente. Así que, puedes simular los data que van y vienen. Y así, puedes tener esas pruebas deterministas. Y así, puedes probar toda tu interfaz de usuario de front-end sin que nunca toque una database. Y puedes hacer que esas pruebas se ejecuten rápido y obtener esa información lo más rápido posible. Y puedes ejecutar tus pruebas rápidamente. Google ha estado experimentando con este tipo de cosas desde 2008. Pero se ha vuelto más convencional porque ellos no... Google tenía muchos ingenieros tratando de resolver este problema. Muchas empresas no necesariamente tienen los ingenieros tratando de resolver esto. Están tratando de resolver sus propias necesidades de producto para poder vender y mantener a los ingenieros con salarios. Y por eso, es importante poder hacer tus pruebas lo más pequeñas posible. Resuélvelas para lo que deberían estar haciendo y luego sigue desde allí.

Lo siguiente es si necesitas probar en móvil, como he mostrado con Nightwatch, Nightwatch configurará tus dispositivos móviles para ti. Y deberías usarlos cuando sea posible. Aprecio completamente que no todo el mundo puede tener un Mac. Y entonces, se trata de riesgo y cosas así. Y entonces, si no tienes un Mac, así que no puedes probar en Safari, discúlpame, o iOS, prueba en WebKit. Pero sabe que hay diferencias entre WebKit en escritorio y en dispositivos móviles. Porque los dispositivos móviles la forma en que renderiza todo es diferente. Así que, necesitas pensar en cómo rompes... Piensas en el riesgo cuando se trata de pruebas de extremo a extremo. Porque sé de una gran empresa que perdió millones porque probaron Safari cuando Chrome estaba basado en WebKit en lugar de Chromium, o Blink, lo siento. Probaron Safari con Chrome. Pero había diferencias y los bugs se colaron. Y les costó millones. Y entonces, es algo basado en el riesgo.

Desafíos de la Testabilidad en los Frameworks de Front-end

Short description:

Discute la importancia de tener pequeños conjuntos de pruebas y el impacto que puede tener en acelerar el despliegue a producción. Menciona el cambio de las pruebas de extremo a extremo a las pruebas de componentes como una forma de aumentar el determinismo y reducir el número de pruebas necesarias. Destaca la falta de enfoque en la testabilidad en los frameworks de front-end y expresa frustración con el estado actual de las pruebas en estos frameworks.

Entonces, es cómo lo haces. Me interesa si las personas están dispuestas a... Cuando miras tu conjunto de pruebas ahora, y piensas en cuán pequeño vas a hacerlo, ¿crees que podrías hacer un gran cambio en tu empresa? ¿O crees que ya estás haciendo eso? En mi experiencia, hoy en día, no trabajo para ninguna empresa. Pero tuve la oportunidad de estar muy seguro en el pasado cuando el pipeline estaba en verde para desplegarlo a producción. Especialmente, porque estábamos haciendo lo que estás mencionando en esta masterclass aquí. No nos preocupábamos solo por la cima de la pirámide. Pero en cambio, teníamos muchas más pruebas en la base de la pirámide tareas de integración, y solo las pruebas que eran necesarias, porque serían más inestables, serían más lentas. Entonces, si tienes este tipo de enfoque, entonces creo que estás en buena forma para desplegar a producción más rápido. Si no, entonces estás en grandes problemas. He estado en la situación opuesta también. Y fue mucho más difícil cuando todo se basaba en pruebas de extremo a extremo, entonces es más largo, pasas mucho tiempo depurando, muchos de los fallos no son fallos reales. Y luego simplemente te hace lento al final. Y he visto también a empresas moviéndose de pruebas de extremo a extremo a pruebas de componentes, donde tienes mucho más control sobre lo que estás probando. Y luego, debido a pasar de extremo a extremo a componentes, poder tener mucho más determinismo en sus ejecuciones de pruebas, y poder reducir la cantidad de pruebas de extremo a extremo que son necesarias. Sí. Me alegra que haya otras personas pensando de esta manera. Creo que en su mayoría, cuando se trata de pruebas de extremo a extremo, es un equilibrio. Y los sistemas hoy en día son súper fáciles de configurar para hacerlo. Como que todo el mundo es súper fácil de hacer. Y creo que el determinismo no es tan difícil de configurar ahora en tus pruebas, donde al menos cuando comencé mi carrera, era muy difícil, y había mucha inestabilidad, pero las herramientas han avanzado mucho. Me encantaría escuchar de ti acerca de la testabilidad porque esto es algo también de lo que la gente no habla mucho. Una cosa es decir que la tarea debería ser determinista, la otra cosa es añadir testabilidad en la aplicación que estás construyendo. Así facilita escribir las tareas de una manera determinista. Sí. Aquí es donde me subo a un caballo muy alto. Realmente odio los frameworks de front-end en este momento, porque la testabilidad y los frameworks de front-end son dos cosas separadas. Una de las cosas que disfruté en Test.js Summit es que fui a la cena de los oradores, al día siguiente fue el Día de Desarrollo de React. Olvidé el nombre de ello. Pero de todos modos, hubo un Día de React al día siguiente y tuve la oportunidad de conocer a muchos de los oradores del evento de React. Pero ellos eran como desde el principio, y yo estaba como, pero ellos no solo estaban trabajando con React, sino que también tenían sus pequeños proyectos que se basaban en React o React. Y una de mis preguntas favoritas para ellos fue, ¿cómo ves las pruebas? Entonces, si yo... Hablé con alguien alrededor de Solid JS que estaba haciendo algo allí, y yo estaba como, Solid.js, he oído hablar de esto. Es realmente genial. He ido a tu sitio web. No puedo ver cómo hacer pruebas. Ni siquiera como Playwright o Cypress o algo así, ¿verdad? Por ejemplo. Y los ejemplos, como es genial que tengan todas estas cosas. Ninguno de ellos piensa en la testabilidad. ¿Verdad? Puedo ver cómo hacer cosas, pero no puedo ver cómo probarlas. Y entonces he ido a tutoriales, he ido a ejemplos. Simplemente no está allí. Astro.js tiene cosas. Fui allí y hablé con uno de las personas y ellos estaban como, en realidad, sabes, nos encanta compartir diferentes formas de escribir pruebas. Y entonces tienes la prueba por prueba, dependiendo de cómo lo digas. Cypress, añadí Nightwatch.js

Desafíos de Testabilidad en los Frameworks de Front-end

Short description:

Expresa frustración por la falta de testabilidad en los frameworks de front-end y la necesidad de que los frameworks de front-end prioricen las pruebas. Destaca los desafíos de las pruebas en aplicaciones móviles, particularmente con React Native. Enfatiza que la testabilidad es una responsabilidad conjunta entre los usuarios de frameworks de front-end, SDETs, profesionales de QA y gerentes. Anima a hacer las aplicaciones más testables para evitar pruebas flaky causadas por cambios en la UI. Expresa gratitud a la audiencia y proporciona formas de conectar en las redes sociales y un servidor de Discord.

cosas y tienes Playwright. Entonces, en primer lugar, creo que muchos de estos proyectos no son muy buenos. Y luego tienes gente como React, que cuando habla de testing, porque lo hace, ya no es obvio. Esto es cuando se trata de testabilidad. Realmente odio los frameworks de front-end en este momento en general, por eso. Y en realidad, creo que podría intentar armar un par de charlas este año sobre eso. Como para conferencias de frameworks de front-end para llamar específicamente la atención sobre lo mal que están pensando en testing. Como cuando se trata de móviles, no sé si alguno de ustedes ha mirado el móvil, React Native para hacer eso testable, tienes que usar, como, pruebas de caja gris, lo cual está bien. Pero si quisieras hacer esa una prueba de extremo a extremo, tienes que romper la accessibility para hacer tu aplicación testable, porque tienes que hacer que Appium funcione a través de las APIs de accessibility para hacer funcionar React Native. Y sé que hay no muchas personas que pueden apreciar las diferencias que existen. Y entonces creo que en su mayor parte, cuando se trata de testabilidad, hay dos factores principales. El primero, el framework de front-end debería solucionarlo. El otro es, y voy a generalizar, es una afirmación general, pero la calidad es el trabajo de todos. Entonces, si eres un usuario de un framework de front-end y eres un usuario de un framework de front-end, deberías poder hacerlo. Y los SDETs y el personal de QA necesitan hacer algo testable, deberían poder entrar y cambiarlo y tener la confianza para hacerlo. Y los gerentes, especialmente los gerentes de ingeniería, deberían pensar en cómo apoyar a esas personas en esos puntos. Creo que eso es realmente, realmente importante, porque, como, habrá personas, especialmente si lo han visto en Selenium tantas veces, dirán, he escrito este X path para llegar a mi elemento. Y lo miras y dices, sí, pero si cambias una cosa en ese camino, como tu UI ligeramente, tus pruebas van a ser flaky, van a fallar, y luego vas a tener que averiguarlo. Entonces vas a tener que averiguar ese X path, ¿por qué no simplemente hacer algo más testable? Y es eso. No creo que la gente tenga suficiente agencia para llegar a ese punto o la confianza para hacerlo, especialmente porque la community de desarrollo mira con desprecio a los testers. Y gracias a todos por unirse. Que tengan un fantástico resto de su día, noche. Pueden encontrarme en las redes sociales como automated tester. Solo envíenme un mensaje. Como si estás en Twitter o en Blue's Go, en cualquiera de esos lugares, estoy allí. Solo envíenme preguntas por DM, puede que no llegue a ustedes de inmediato pero definitivamente les responderé tan pronto como pueda. Hay un canal de Discord, un servidor de Discord para Nightwatch en el que estoy, si quieren venir a pasar el rato. Por favor, únanse. Feliz Halloween para todos y cada uno. La community es increíble. Siempre es útil para cualquiera. Pueden hacerme preguntas allí también. Pero de lo contrario, que tengan un buen resto de la noche y gracias a todos.

Watch more workshops on topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.