Frameworks de Pruebas, Frameworks Móviles y los Navegadores Aman a los Desarrolladores y Testers

Rate this content
Bookmark
Centrarse en estar donde están tus usuarios no es tan difícil como piensas. Muchos grupos ahí fuera te dirán que su herramienta es la mejor y que aunque ninguno de tus usuarios use ese navegador o configuración móvil está bien. En esta charla, David hablará sobre todas las diferencias que surgen, por qué los proveedores de navegadores incluso están diciendo a la gente que no se centren en los motores de navegadores o doms virtuales, y cómo la configuración de los entornos de desarrollo es simple de establecer estos días.

Al ignorar el amor que se está impulsando a los desarrolladores y testers a través del trabajo que se está realizando, puede haber pruebas que están pasando pero tus usuarios están fallando en usar tu aplicación! No te preocupes, David tendrá los ejemplos del mundo real para mostrarte cómo están las cosas rotas :)

27 min
07 Dec, 2023

AI Generated Video Summary

La charla de hoy cubrió varios temas, incluyendo frameworks de pruebas, navegadores, y los desafíos enfrentados en la prueba de sistemas complejos. Se destacó la importancia de mejorar la configuración de las pruebas y la productividad, junto con el principio de menor sorpresa y la necesidad de actualizaciones de frameworks. La charla también discutió los diferentes motores de navegadores y sus características únicas, así como los beneficios de compartir ideas y enfoques dentro de la comunidad de desarrollo de software. La sesión concluyó con ideas sobre pruebas de navegadores y el uso de herramientas como Playwright y WebKit.

1. Introducción a los Marcos de Prueba y Navegadores

Short description:

Hoy, voy a hablar sobre los marcos de prueba, los marcos móviles, los navegadores y cómo a las personas detrás de ellos les encantan los desarrolladores y los probadores que utilizan sus productos.

♪♪♪ Hola a todos. Mi nombre es David. Y hoy voy a hablar sobre testing frameworks, marcos móviles, navegadores, y cómo cada una de las personas que trabajan en ellos aman a los desarrolladores y probadores que utilizan sus productos. La razón por la que sé esto es, como dijo Nathaniel, he estado en la industria durante un tiempo. Pasé casi una década trabajando en Firefox. He estado haciendo automatización de navegadores durante casi dos décadas. Y así que cada vez que veo estas cosas y vengo a estas conferencias y veo lo que la gente está haciendo y mostrando, todo lo que veo es el amor que tienen y quieren mejorar todo. Y quiero que nos importe. Quiero que todos en esta sala digan, en realidad, es agradable ver que les importa.

2. Desafíos en las Pruebas y Simplificación de Enfoques

Short description:

Las pruebas son difíciles. Los sistemas con los que trabajamos son increíblemente complejos. Tenemos navegadores, aplicaciones web y múltiples capas a través de todo el sistema. Numerosas personas han intentado simplificar las pruebas con términos como la pirámide de pruebas, pruebas unitarias y pruebas de integración.

Y entonces vamos a empezar con algo que creo que es como un árbol. Testing es difícil. Cuando miramos cómo queremos hacer nuestro trabajo, empezamos con testing y decimos, en realidad, ¿sabes qué? Testing es muy, muy difícil. Las personas construyen carreras en torno a ello, ¿verdad? Y aún así dicen, no tengo idea de lo que estoy haciendo. Y está bien.

Y la razón principal por la que testing es tan difícil es que los sistemas contra los que trabajamos son increíblemente complejos. Pensamos en JavaScript. Es un lenguaje asíncrono. Hemos estado haciendo esto. Pero cuando pensamos en testing, pensamos secuencialmente. Queremos ir de este paso a este paso a este paso. Así que hace muchos años cuando empecé mi carrera, había un infierno de callbacks. Y lo intentabas y esperabas que las cosas se ejecutaran en el momento adecuado. El lenguaje ha mejorado y es mucho, mucho mejor. Pero luego tenemos otras cosas que se interponen. Tenemos navegadores. Tenemos web apps. Tenemos todo, desde múltiples capas a través de todo el sistema que tenemos que probar. Y pensamos en cómo lo hacemos y decimos, en realidad, esto es realmente difícil. Pero, hemos tenido como numerosas personas pensando en cómo abordamos estos problemas. Y han intentado simplificarlos a medida que avanzan. Y han surgido con términos bastante geniales como la pirámide de testing, unit testing, pruebas de integración y así sucesivamente. Y voy a desglosarlo. Porque creo que es importante que a veces las palabras importan. A veces no creo que importen tanto.

Y entonces, con el unit testing, esto es donde creo que la gente se obsesiona un poco, pero han intentado desglosar el problema en algo pequeño. Y es una prueba pequeña. Porque a veces la gente no puede hacerlo a nivel unitario. Y tenemos estas pruebas de integración donde probamos nuestros contratos. Y aquí es donde empezamos a ver algo del verdadero amor que la gente tiene.

3. Herramientas de Pruebas, Frameworks y Complejidad del Navegador

Short description:

Obtenemos herramientas como Mocker y VTest que nos permiten hacer pruebas en JavaScript. Probar los frameworks de front-end es un desafío debido a su complejidad. Los diferentes navegadores y navegadores móviles añaden a la complejidad. Los cambios del equipo de Chromium al navegador Headless muestran su cuidado por los desarrolladores. Sin embargo, las actualizaciones frecuentes pueden ser frustrantes.

Obtenemos herramientas como Mocker y cosas así que han crecido, y herramientas más nuevas, VTest, que han surgido para permitir a las personas hacerlo. Testing en JavaScript cuando comencé mi carrera fue mucho de simplemente hacer clic manualmente, asegurándonos de que las cosas funcionaran como lo anticipamos. Y no fue tan fácil.

Y luego tenemos herramientas geniales que están saliendo que nos permiten pensar un poco más grande, pero no tan grande como una prueba de extremo a extremo. Y tenemos esas pruebas de componentes. Hemos visto el mercado explotar con personas tratando de probar sus frameworks de front-end, que son realmente difíciles de probar porque son complejos. Tienen su propia complejidad incorporada.

Y luego tenemos estas pruebas medianas a grandes, como me gusta llamarlas. Y las pruebas medianas a grandes son, al menos estás iniciando un navegador, pero no estás haciendo una prueba completa de extremo a extremo. Y luego tenemos nuestras pruebas de extremo a extremo. Y entonces tiene toda esta complejidad. Y luego lanzas diferentes navegadores, ¿verdad? Solo he mostrado aquí variaciones de Chromium, pero tienes Firefox, tienes Safari, y luego tienes navegadores móviles encima de eso. Y esta complejidad es algo en lo que todos empiezan a pensar, pero cuando se trata del caso de resolverlo, mejorarlo, hacer ese trabajo, es muy difícil. Pero tiene que haber alguien que se preocupe y quiera hacerlo.

Pero tenemos toda esta complejidad. Así que tenemos nuestros frameworks, tenemos navegadores, y a veces los navegadores no son siempre los navegadores que esperamos que sean, ¿verdad? A principios de año, el equipo de Chromium dijo, oh, por cierto, Headless no es lo que crees que es. Headless es un navegador totalmente diferente en Chrome. Así que todas tus pruebas que has estado haciendo, pensando que has estado haciendo lo correcto, tal vez no sea realmente cierto, y lo sentimos por eso. Pero lo arreglamos, ¿verdad? Entonces, lo siento por eso. Así que ahora, no solo tienes variaciones de Chromium, navegador Headless en el que estás pensando, y estás tratando de mejorar tus pruebas, y no está yendo como quieres. Pero esta es una primera señal de que el equipo de Google realmente se preocupa por nosotros. Han visto el problema. Han dicho, en realidad, esto está causando más problemas de los que nos importan. Así que vamos a solucionarlo. Y esta es otra señal de que nuestros desarrolladores nos aman.

Pero luego, pasamos directamente de que nos aman a que nos odian de nuevo. Actualizando cada cuatro a ocho semanas, ¿verdad? Cuando comencé en Mozilla, el año anterior se había lanzado Firefox 3.6, soy tan viejo, y estábamos a seis meses de que se lanzara Firefox 4. Mozilla decidió tener este maravilloso grupo de masterclass donde se reúne toda la empresa. Y en esa etapa, Mozilla era unas 350 personas. Así que éramos pequeños.

4. Envío de Chromium e Incremento de la Frecuencia de Lanzamiento

Short description:

Invitaron a un Googler quien anunció que estarían enviando Chromium cada 12 semanas para acelerar el ritmo de la web. Internet Explorer había renunciado, mientras que Firefox estaba creciendo. El equipo de Chromium reconoció la necesidad de velocidad y desde entonces ha aumentado su frecuencia de lanzamiento. El ciclo de lanzamiento de ocho semanas evita los períodos de vacaciones para garantizar operaciones sin problemas.

Invitaron a un Googler. El Googler dio una charla a toda la empresa, y dijo, por cierto, vamos a estar enviando Chromium, porque Chrome era nuevo en el mercado. Vamos a estar enviando cada 12 semanas. La web no se está moviendo lo suficientemente rápido. Necesitamos que se mueva más rápido. Internet Explorer había renunciado. Y estaban haciendo lo que necesitaban al mínimo indispensable. Firefox estaba creciendo, construyendo cosas. Y luego el equipo de Chromium dijo, sí, necesitamos hacer esto más rápido. Y solo ha ido más rápido desde entonces. Las ocho semanas son normalmente alrededor de la época de Navidad o alrededor del 4 de julio, cuando los equipos de EE. UU. necesitan tomar un descanso, y no quieren estar enviando entonces, porque si algo sale mal, alguien va a tener que trabajar durante los períodos de vacaciones.

5. Mejorando la Configuración de Pruebas y Mejorando la Productividad

Short description:

Las herramientas actuales te permiten configurar fácilmente un nuevo proyecto, incluyendo dispositivos y navegadores. Puppeteer, Cypress, Playwrights, Nightwatch, JS y WebDriver I-O se han centrado en simplificar la configuración y mejorar la experiencia de prueba. Los frameworks como React ahora proporcionan una forma estándar de configurar proyectos, facilitando el inicio en el espacio de JavaScript. Estas mejoras buscan mejorar la productividad y abordar los desafíos de trabajar con lenguajes asíncronos.

Entonces, he hablado un poco del amor de los desarrolladores, los desarrolladores de Chromium, pero ¿dónde está el amor para la testing community? ¿Dónde estamos viendo esas cosas que hacen nuestra vida más fácil, mejor, más rápida, más productiva? ¿Y dónde estamos viendo esos elementos? Y los vemos con las tooling de hoy en día que te permiten, necesito configurar un nuevo proyecto. ¿Cómo lo hago?

Entonces, configurar dispositivos, configurar navegadores, ¿verdad? He estado trabajando en Selenium durante unos 16, 17 años, ¿verdad? De una forma u otra. En ese tiempo, nunca te dimos las tooling para descargar un navegador, configurarlo, principalmente porque asegurarse de que fuera consistente en todas partes era difícil. Y los proyectos de código abierto son en su mayoría dirigidos por voluntarios. Hay algunas excepciones, pero configurarlos era difícil, pero intentamos hacer todo lo demás mientras tanto. Así que, trabajamos con el W3C y conseguimos drivers y estandarizamos todo y los pusimos en su lugar. Y luego conseguimos configurar las dependencias. Estoy seguro de que todos han visto como con el testing de componentes, queremos asegurarnos de que tienes todo lo que necesitas. Pero los frontend frameworks tienen sus propias especialidades. Así que, se trata de descargar esto, descargar esto, sin saber cuándo hacerlo.

Puppeteer comenzó famosamente con esto, en realidad descargaremos el Chromium para ti. Nos aseguraremos de que puedas descargarlo, ejecutarlo en tu primer intento. No podías hacer eso con Selenium, a menos que ya tuvieras un navegador y supieras cómo iniciar ese navegador. Pero había un poco de complejidad allí. Lo hemos visto crecer con Cypress y Playwrights, Nightwatch, JS. Trabajo en eso ahora. WebDriver I-O, todos han dicho en realidad, vamos a configurar todo y mejorarlo. Así que, puede que no te digan que te cuidan, que te quieren, pero sus acciones están empezando a demostrarlo. Y hemos llegado a la etapa en la que podemos mejorar las cosas.

Entonces, en este caso, como MPM y Nets, lo vemos con React y otros proyectos hoy en día, donde puedes simplemente decir, quiero configurar un proyecto. Podrías hacerlo. Entonces, la imagen de la derecha, si no puedes verla, está bien. Pero las últimas tres líneas son como, ¿quieres hacer testing de extremo a extremo? ¿Quieres hacer testing de componentes? ¿Quieres hacer testing de web móvil o de aplicación móvil? Y luego respondes un par de preguntas. Nos dices dónde vamos a ejecutarlo, y lo ejecutamos. Y nos aseguramos de que todo esté en su lugar. Te damos ejemplos de pruebas. Esto se ha convertido ahora en una forma estándar para que los frameworks configuren todo, porque empezar en un espacio de JavaScript es difícil, porque pensamos secuencialmente, y tratamos de hacer todo secuencialmente. Y tratamos de resolver estos problemas en un lenguaje que es asíncrono y no siempre funciona secuencialmente de la manera que queremos. Y así trata de mejorar estas cosas. La otra cosa que se está intentando mejorar a lo largo del espacio es el principio de menor asombro.

6. Principio de Menor Sorpresa y Actualizaciones de Framework

Short description:

El principio de menor sorpresa es importante. Las actualizaciones de framework pueden romper las pruebas, causando frustración para los usuarios. Debería ser posible actualizar pequeñas partes a través de las herramientas para garantizar la confianza y el progreso.

O prefiero el principio de menor sorpresa. Entonces, cuando obtienes algo, deberías saber intuitivamente cómo usarlo. Si trabajas en ello, como si vas a un cliente de correo y quieres enviar un correo electrónico, debería ser obvio que hay un botón de redactar o un botón de nuevo correo electrónico, cosas así.

Si estás trabajando en una API, deberías poder hacer esto, punto, hacer aquello, punto, y debería permitirte avanzar si lo deseas de esa manera, o simplemente piensas, creo que esto es lo que necesito. Necesito extraer esta información. Y debería ser intuitivo hacerlo.

Donde algunos frameworks han comenzado a fallar, y esto es principalmente cuando se vuelve a cómo Selenium nunca te permitió descargar y siempre te obligó, otros frameworks decían, lo descargaremos por ti, es que actualizar esos navegadores hoy en día significa que tienes que actualizar su framework, lo que luego puede causar otros problemas, pero no necesariamente porque no te quieran, es que su amor podría mostrarse de una manera diferente. Y así, a veces, actualizar el framework puede romper tus pruebas. Sé que he visto esto antes con los usuarios de Puppeteer. Decían, estoy atascado en una versión muy antigua de Puppeteer porque cada vez que lo actualizo, mis pruebas fallan. Simplemente no puedo manejar eso. No tengo tiempo para arreglar mis pruebas. Y así deberías poder, a través de tus tooling, lo que sea, poder actualizar pequeñas partes, tener la confianza y seguir adelante.

7. Motores de Navegadores y Frameworks

Short description:

Los motores de navegadores no son iguales a los navegadores. Diferentes navegadores como Brave, Opera, Vivaldi y Edge tienen sus características únicas. Selenium Manager ayuda a actualizar los controladores para Chrome, resolviendo el dolor de la compatibilidad. El equipo de Chromium creó Chrome para Pruebas para proporcionar una forma estándar de rastrear errores. Frameworks como Nightwatch.js configuran simuladores y emuladores para pruebas móviles. Escalar en navegadores móviles y de escritorio tiene sus desafíos, pero los frameworks y herramientas muestran cuidado y amor por los desarrolladores, y la mayoría de ellos son de código abierto.

Y esto es donde, más o menos, es un poco un caballo de batalla mío en este momento. Los motores de navegadores no son iguales a los navegadores. Si piensas en la diapositiva de Chromium de antes, teníamos seis versiones diferentes de Chromium allí, ¿verdad? Si hablo con Brendan Eich, quien es el CEO de Brave, él te dirá una o dos cosas que son iguales a Google Chrome o Chromium, pero Brave es único. Lo mismo con Opera, Vivaldi, Edge, ¿verdad? Todos toman sus cosas diferentes. Entonces, ¿cómo resolvemos esto? Entonces, en el espacio de Selenium, en el que paso mucho tiempo, tenemos herramientas como Selenium Manager. Así es como el proyecto Selenium intenta mostrarte que les importa, es que quieres actualizar tus controladores para Chrome porque Chrome driver tiene que usar el protocolo de depuración de Chrome, que cambia con cada versión de Chrome. Y necesitas actualizar eso. ¿Qué tal si simplemente eliminamos ese dolor, lo resolvemos por ti? La otra cosa que la gente tiene, que estábamos viendo, es que, como, el equipo de Puppeteer se estaba frustrando con la forma en que la gente estaba planteando problemas. Este error está ocurriendo con Puppeteer en Chromium. Y ellos dirían, bueno, no puedo reproducir esto en Chrome. Y entonces lo que hicieron, el equipo de Chromium, fue que crearon Chrome para Pruebas. Y Chrome para Pruebas es para evitar que uses Chromium en tu entorno de pruebas porque no está destinado a ser utilizado como un navegador de pruebas porque no hay forma de ir desde tengo este error y rastrearlo hasta el commit que causó ese error. Porque las cosas están cambiando tan rápido en esa base de código que es bueno tener una forma estándar de hacerlo. Entonces, Puppeteer, Selenium, cosas así, lo usan. Y ha surgido a través de la colaboración, mejorando lo que queremos, que la gente empiece a preocuparse. Y luego viene el otro lado de eso, ¿verdad? Encoger escritorios no es móvil. Es un poco controvertido para algunas personas, pero es cierto. Y la razón principal es cómo los sistemas operativos renderizan las páginas web. Se vuelven complejas, cosas así. Si pasas algún tiempo con un desarrollador de Chromium que está trabajando en Android, o un ingeniero de Firefox trabajando en Android, o un ingeniero de Safari trabajando en iOS, puede ser difícil. Pero la forma en que los frameworks están empezando a mostrar a la gente que se preocupan y te quieren es que vemos este problema difícil, lo configuraremos por ti. Entonces, uno de los proyectos en los que trabajo, Nightwatch.js, configura simuladores y emuladores por ti si quieres hacer pruebas en móvil. Y no depende de Appium para hacer cosas si te importa solo la web. Porque Chrome driver, Gecko driver, Safari driver, funcionan bien con los navegadores móviles. Entonces, usemos navegadores móviles. Te daré una cosa, escalar en móvil es difícil. Pero escalar en navegadores de escritorio también es difícil, solo de una manera ligeramente diferente. Quizás de una manera menos costosa, pero sigue siendo difícil. Y entonces la gente te está dando su amor y te está dando los frameworks y las herramientas. Y todo esto es gratis hoy en día, gracias al código abierto.

QnA

Compartiendo Ideas y Enfoques de Frameworks

Short description:

Uno de los beneficios de ser un MC es que puedo hacer una pregunta primero. ¿Hay algún barco que veas que simplemente entra en la estación, sale de la estación y luego vuelve a dar la vuelta, que tal vez deberíamos empezar a poner en su lugar permanentemente? El espacio de JavaScript parece muy voluble a veces. Los frameworks de la vieja guardia siguen creciendo. La singularidad de la web siempre trae algo que avanza, no necesariamente dando vueltas en círculo. Tenemos un par de preguntas entrantes. La primera pregunta es sobre un framework diferente. ¿Qué crees que es diferente en el enfoque del equipo de Nightwatch en comparación con otros frameworks de front end end-to-end como Cyprus o Playwright?

Creo que una de las cosas que sería increíble para las personas en esto, alrededor del mundo, es compartir sus ideas de características. Creo que me gustaría esto o aquello. Estos son los puntos de dolor que tengo regularmente con tu framework. Hay mucho ruido que viene en muchos frameworks y proyectos. Pero cuando hay alguien diciendo, oye, me encanta esta idea, ¿podrías ayudarme a hacerla? Estoy bastante seguro de que cada proyecto que usas estaría dispuesto a ayudar. Así que comparte tus ideas, porque compartir tus ideas es mostrar tu amor a cambio.

Y con eso, he llegado al final de mi charla. Gracias a todos. Así que sí. Uno de los beneficios de ser un MC es que puedo hacer una pregunta primero. Una pregunta que me he estado preguntando es, como dijiste, has estado en, especialmente en la automation de navegadores durante más de 20 años, ¿verdad? Así que has estado aquí por un tiempo. Has visto llegar muchos barcos. Has visto irse a muchos barcos. ¿Hay algún barco que veas que simplemente entra en la estación, sale de la estación, luego vuelve a dar la vuelta, que tal vez deberíamos empezar a poner en su lugar permanentemente?

Yo, no realmente. Creo que lo interesante que está sucediendo es que el espacio de JavaScript parece muy voluble a veces, ¿verdad? Y, pero cuando lo miras, algunas de las cosas que siempre están ahí, la vieja guardia, todavía están ahí. Simplemente podrían no obtener la publicidad que obtenían, digamos, hace cinco, 10 años. Y así como si solo fueras por puro sentimiento, la gente te dirá que, oh, Cyprus y Playwrights están creciendo y están haciendo esto. Están creciendo y son herramientas fantásticas, ¿verdad? Pero al mismo tiempo como los viejos guardias, Lenium, cosas así, todavía están creciendo como un 25% trimestre a trimestre, ¿verdad? Y así que no veo cosas así. Las cosas que he visto son cómo las personas abordan el problema. Entonces a veces era como, oh, podemos simplemente inyectar JavaScript en la página. Eso será bueno. Y comenzamos con eso originalmente con Lenium y nos alejamos de eso. Cyprus luego lo trajo de vuelta. Y así causa algunos problemas, pero no. Pero es la singularidad de la web, siempre hay algo avanzando, no necesariamente dando vueltas en círculo. Sí, totalmente. Siempre avanzando, me gusta.

Bueno, tenemos un par de preguntas entrantes. La primera pregunta es sobre un framework diferente. Entonces, ¿qué crees que es diferente en el enfoque del equipo de Nightwatch en comparación con otros frameworks de front end end-to-end como Cyprus o Playwright? Esta es una adición atrevida a la pregunta.

Frameworks de Pruebas y Pruebas de Navegador

Short description:

Nightwatch y Playwright hablan a través del backend del navegador, lo que lo hace más realista. No se recomienda la prueba sin cabeza para las tuberías de CI/CD ya que puede perder errores que ocurren en navegadores específicos. Usar navegadores con cabeza tanto como sea posible ayuda a evitar sorpresas y rastrear errores. Al trabajar con solicitudes de servidor, la pirámide de pruebas es un concepto útil.

¿Por qué es mejor? Entonces, la forma en que Nightwatch y WebDriver son filosofías centrales, estar donde está tu usuario, ¿verdad? Entonces, si vas a hacer pruebas, haz pruebas de componentes, asegúrate de que esté en un navegador, no usando jsdom, porque eso en realidad causa otros problemas. Y es como ese problema de Chromium versus Chrome que puede surgir y tienes estas diferencias.

Lo que creo que es como Nightwatch es, personalmente, creo que Nightwatch es mejor que Cyprus porque Cyprus usa como, la forma en que habla con el navegador está usando tecnología más antigua como Selenium RC. Y si escribes cualquier JavaScript en una página, estás limitado por el sandbox en el navegador porque es un sistema de security, ¿verdad? Está tratando de mantener a todos a salvo y no está diseñado necesariamente para automation donde la forma en que Nightwatch y Playwright lo hacen es que habla a través del backend del navegador y dice, oye, ¿puedes manipular estas cosas para nosotros? Y entonces es más realista. Y en ese caso, creo que es realmente bueno. Creo que hay muchas similitudes entre Playwright y Nightwatch y especialmente con el trabajo que se está realizando en el W3C para WebDriver Bidi para estandarizar algunas de esas ideas básicas para que Mindwatch pueda mejorar a medida que avanza y sea estándar. Sí, gracias. Gracias. Esa fue una muy buena pregunta y una gran respuesta. Tenemos otra y esto está relacionado con algo de lo que hablaste sobre el navegador. Entonces, ¿esta prueba reemplazó las pruebas del navegador? Entonces, si no, ¿por qué probamos headless ya que ningún usuario final va a estar en headless? Si es así, entonces, ¿por qué hacer pruebas cruzadas de navegador? No estoy seguro de entender bien, pero también puedes leerlo allí a la derecha. Vale. ¿Puede headless reemplazar? No, no creo que pueda. He estado en el campamento que intentaba decirle a la gente cuando la gente se movía a headless, lo mismo con Richard Bradshaw del Ministerio de Pruebas o ex-Ministerio de Pruebas fue que headless no es donde están tus usuarios. Es genial si estás desarrollando localmente y no quieres ver navegadores apareciendo todo el tiempo, ¿verdad? Eso puede ser molesto. Y entonces está bien. Pero en el momento en que entra en tu tubería de CI CD debería estar donde están tus usuarios, los mismos navegadores, lo que sea. Y tienes una matriz y simplemente construyes y pruebas a través de ella. Y deberías hacer eso tanto como sea posible para que puedas atrapar errores, ¿verdad? Entonces, como mi error favorito de motor de navegador versus navegador fue uno donde hace un par de años, IndexedDB estaba roto en Safari, ¿verdad? Realmente, realmente roto.

Pruebas con Playwright y WebKit

Short description:

Si estuvieras probando con Playwright y WebKit, nunca te encontrarías con un error que solo ocurre en el escritorio. El principio de la menor sorpresa sugiere utilizar navegadores con cabeza tanto como sea posible. Cuando se trata de solicitudes del servidor, la pirámide de pruebas sugiere usar simulacros para pruebas de componentes y evitarlos para pruebas de extremo a extremo. El equilibrio radica en tener ciclos de retroalimentación rápidos y no depender de los simulacros en todas partes. Se espera que Chrome para pruebas resista la prueba del tiempo, proporcionando una experiencia de navegador determinista mientras se mantiene al día con las actualizaciones a través de herramientas como Puppeteer y Selenium Manager. No hay tiempo para más preguntas, pero David estará disponible durante todo el día y en la sala de discusión de los oradores.

Pero si estuvieras testing y como Playwright con WebKit, nunca te encontrarías con ese error porque WebKit no lo tenía, ¿verdad? Y entonces iOS Safari tampoco lo tenía. Pero solo estaba en el escritorio, ¿verdad? Y entonces tenías este extraño error que tu CI CD habría estado pasando. Y esto va en contra de mí, el principio de la menor sorpresa o menor asombro, ¿verdad? Como que no deberías estar obteniendo sorpresas así. Y no hay forma de rastrearlo.

Entonces, uso navegadores con cabeza tanto como sea posible, pero entiendo que hay compensaciones, ¿verdad? Entonces. No, totalmente, sí. Y me encanta el camino de la menor sorpresa. Lo usaré de nuevo. En el futuro. Y estamos trabajando en navegadores y alguien pregunta, especialmente con la forma en que funciona la web, como, vamos a tener solicitudes del servidor. Entonces, ¿deberíamos tener solicitudes simuladas de un servidor o no? ¿Y por qué? Creo que la pirámide de testing aquí entra muy rápido. Como cuando tienes tus pruebas de extremo a extremo, no uses simulacros, pero si estás haciendo pruebas de componentes, haz simulacros, ¿verdad? Como poner todo adentro. Haz esas pruebas lo más rápido posible porque realmente quieres fallar lo más rápido posible, ¿verdad? Como ThoughtWorks hace décadas, cuando sacaron sus CI, las tuberías, decían que, sí, las compilaciones no deberían tardar más de 10 minutos porque la gente se distrae, ¿verdad? Como los teléfonos móviles hoy en día, la gente dice, oh sí, estaba bien construyendo, hagamos esto. Y es como, oh espera, he perdido una hora, ¿verdad? Como tener esos ciclos de retroalimentación rápida definitivamente tienen simulacros y luego, pero es un equilibrio. No lo hagas en todas partes. No, totalmente.

Muy bien, tenemos tiempo para una última pregunta rápida, que es especialmente sobre la prueba del tiempo. ¿Crees que Chrome para testing pasará la prueba del tiempo? ¿No es mejor estar donde está tu usuario, que en mi opinión es el punto de tu charla, ¿verdad? Sí, creo que va a resistir la prueba del tiempo, ¿verdad? Como cuando se trata de testing, necesitamos, estoy tratando de pensar en la palabra correcta aquí. Necesitamos asegurarnos de que nuestras pruebas son deterministas. Esa es la palabra que estaba tratando de pensar, ¿verdad? Chrome para testing permite el determinismo, pero todavía puedes, va a ser el mismo Chrome que se envía, pero tienen, han sacado el actualizador automático y entonces estás usando lo que tus usuarios son y ahora no tienes las actualizaciones automáticas, pero luego herramientas como Puppeteer, Selenium Manager, cosas así, deberían estar actualizando esas a medida que avanzan. Entonces estás manteniendo donde están tus usuarios, pero también tienes un navegador determinista en tu sistema. Ahora, totalmente. Muy bien, no tenemos tiempo para más preguntas. Sin embargo, podrás encontrar a David durante todo el día. Y también estará en la sala de discusión de los oradores más tarde. Así que definitivamente acércate y saluda y haz cualquier otra pregunta que tengas. Pero démosle una ronda más de aplausos. Gracias. ♪♪♪

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TypeScript Congress 2023TypeScript Congress 2023
31 min
Making Magic: Building a TypeScript-First Framework
I'll dive into the internals of Nuxt to describe how we've built a TypeScript-first framework that is deeply integrated with the user's IDE and type checking setup to offer end-to-end full-stack type safety, hints for layouts, middleware and more, typed runtime configuration options and even typed routing. Plus, I'll highlight what I'm most excited about doing in the days to come and how TypeScript makes that possible not just for us but for any library author.
React Summit 2022React Summit 2022
23 min
Let’s Talk about Re-renders
React is a fantastic tool to implement complicated applications fast, we all know it. But are they going to be fast when implemented fast? Let’s talk about re-renders and their danger in react: how easy it is to make a mistake, why some small mistakes can have a huge downstream effect, and how to avoid and prevent them.This is a deep-dive type of talk, that focuses on why React components re-render, what kind of performance impact it can have, and what to do about it

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
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
TypeScript Congress 2022TypeScript Congress 2022
116 min
Advanced TypeScript types for fun and reliability
Workshop
If you're looking to get the most out of TypeScript, this workshop is for you! In this interactive workshop, we will explore the use of advanced types to improve the safety and predictability of your TypeScript code. You will learn when to use types like unknown or never. We will explore the use of type predicates, guards and exhaustive checking to make your TypeScript code more reliable both at compile and run-time. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Are you familiar with the basics of TypeScript and want to dive deeper? Then please join me with your laptop in this advanced and interactive workshop to learn all these topics and more.
You can find the slides, with links, here: http://theproblemsolver.nl/docs/ts-advanced-workshop.pdf
And the repository we will be using is here: https://github.com/mauricedb/ts-advanced