Envío de aplicaciones JS de alta calidad con confianza

Hola a todos. Mi nombre es Tomasz Hokomer y hoy me gustaría hablar un poco sobre cómo podemos enviar aplicaciones JavaScript de alta calidad con confianza. Pero antes de continuar, me gustaría comenzar contándoles una historia rápida. Esta es una historia que realmente sucedió. Pueden ver el enlace aquí. También mostraré las diapositivas más adelante.

Y esta es la historia de cómo una sola empresa con casi $400 millones en activos se declaró en bancarrota por completo en 45 minutos debido a una implementación fallida. La historia es la siguiente. Una firma global de servicios financieros se estaba preparando para una importante actualización de uno de sus sistemas. Querían reemplazar un sistema antiguo que no se había utilizado en ocho años utilizando una variable. No me pregunten por qué tenían ese código en su base de código durante ocho años y por qué decidieron lanzar una variable, porque esta es otra historia por completo.

Pero la historia es la siguiente. Tenían ocho servidores. Y solo copiaron el nuevo código en siete de ellos. Por lo tanto, un servidor todavía tenía el código muy antiguo, lo que causó todo tipo de problemas. Y los problemas fueron tan graves que terminaron negociando ocho millones de acciones cada minuto sin un interruptor clave, sin procedimientos documentados sobre cómo reaccionar. Fue un caos absoluto. Y en resumen, lograron perder $460 millones en 45 minutos debido a una única implementación falsa.

Y les cuento esta historia no para asustarlos de enviar software a producción, sino para convencerlos y resaltar el hecho de que la calidad importa. No solo nos importa la calidad de nuestro software porque queremos ser buenos ingenieros. La calidad de su software también puede hacer o deshacer su negocio. Y la pregunta naturalmente se convierte en ¿cómo enviamos software de calidad? ¿Hay alguna forma significativa, algún elemento único que podamos agregar a nuestro backlog para aumentar la calidad de nuestro software? Y realmente no. Últimamente me he inspirado en este artículo titulado 'No hay bala de plata, la esencia y el accidente en la ingeniería de software'. Y este título es de la década de 1980, de hecho, es más antiguo que yo. Pero sigue siendo completamente cierto, incluso en 2021, porque en el resumen de este artículo, leemos que no hay un solo desarrollo, ya sea tecnológico o técnica de gestión, que por sí solo prometa una mejora de un orden de magnitud en una década en productividad y otros factores. Y lo mismo ocurre con las pruebas. No hay una sola forma, no hay una sola técnica o herramienta o lo que sea que podamos agregar a nuestro conjunto de herramientas para mejorar significativamente la calidad de nuestro software. Tiene que ser una combinación, una colección de diferentes herramientas. Por eso, cuando pienso en las pruebas, me gusta pensar en esta idea de un espectro de pruebas. Todas las diferentes herramientas y prácticas y las formas en que intentamos optimizar la calidad de nuestro software se encuentran en el espectro.

Entonces, existen herramientas y prácticas que están muy cerca del desarrollador y un poco lejos del usuario. Y hay cosas que están muy cerca de la experiencia que estamos entregando a nuestros usuarios. Y una buena práctica de pruebas es básicamente una combinación de todas ellas. Lo cual, por cierto, es algo similar a cómo estamos manejando la pandemia global actualmente. No hay una solución única para el problema, pero en cambio, al aplicar múltiples soluciones, podemos mitigar de alguna manera la propagación de este problema.

Y nuevamente, volviendo al espectro de pruebas, vamos a comenzar con el desarrollador. Entonces, la primera herramienta, que puede ser un poco sorprendente, que me gustaría mencionar es Prettier. Prettier no se piensa típicamente como una herramienta de pruebas, pero aquí está la cosa. Si he escrito un código que tiene algún error de sintaxis, Prettier no hará nada. Por lo tanto, Prettier nos ayuda a minimizar los ciclos del editor, porque cada vez que guardo y mi código no se mueve, ni siquiera tengo que abrir mi navegador. Por lo tanto, puedo iterar rápidamente. Tengo que abrir mi navegador con menos frecuencia, y puedo escribir un mejor software porque puedo iterar más rápidamente y crear mi código de manera más eficiente.

Cuando se trata de otras herramientas que nos ayudan a escribir un mejor código, tengo que hablar un poco sobre TypeScript. He estado usando TypeScript durante un tiempo ahora, y recomiendo encarecidamente usar TypeScript para proyectos medianos, grandes y enormes. Y la razón por la que TypeScript es útil cuando se trata de calidad y pruebas es que los tipos estáticos eliminan cierta clase de errores. Especialmente, eliminan errores como este, undefined no es una función. Eso no es algo que sea muy probable que veas en producción cuando estás usando TypeScript. Por supuesto, tendrás otros errores, pero undefined no es una función probablemente no será uno de ellos. Y la crítica principal de TypeScript, y para que conste, entiendo completamente eso, es cuando intentas hacer la transición de palabras en JavaScript a TypeScript, ver código como este con todas esas anotaciones de tipo es un poco aterrador, por decir lo menos. Definitivamente hay una curva de aprendizaje pronunciada cuando se trata de TypeScript y definitivamente entiendo eso. Pero nuevamente, TypeScript es genial porque también nos ayuda a minimizar esos ciclos del editor. Porque si estoy refactorizando un componente React grande escrito en TypeScript, mientras TypeScript siga quejándose, ni siquiera abriré mi navegador. Seguiré iterando en este código durante el tiempo que sea necesario para que TypeScript esté satisfecho, básicamente. Por lo tanto, puedo iterar rápidamente y cuando finalmente abro mi navegador para probar la interfaz de usuario que he creado, sé que se han eliminado cierta clase de errores de manera efectiva. Por lo tanto, puedo escribir un mejor software y más rápido. En cuanto a TypeScript, recomiendo encarecidamente usarlo solo en modo estricto. De hecho, el modo estricto es recomendado por el equipo de TypeScript, pero está desactivado de forma predeterminada, lo cual tiene sentido porque la gran mayoría de los proyectos están migrando de JavaScript a TypeScript, pero aún así recomiendo encarecidamente activarlo. Una cosa que me gustaría enfatizar es que la seguridad de tipos no significa que tu código esté libre de errores. Lo que significa es que tu código no tiene problemas de tipo. Y eso es todo. Y eso, no es solo eso pero de todos modos tienes que tener en cuenta que también tendrás otros errores porque los tipos no te protegerán de ellos cuando se trata de malentendidos de los requisitos de tu negocio, entre otros.

Porque nuevamente, solo eliminan una cierta clase de errores y definitivamente no todos ellos. No hay una solución mágica. Pero cuando se trata de TypeScript, es algo fácil de alguna manera, como fácil para proyectos nuevos pero es muy difícil para proyectos heredados. Si tienes un proyecto grande de JavaScript que estás tratando de migrar a TypeScript, no es fácil, no es trivial, absolutamente no. Y si te gustaría aprender más sobre TypeScript y especialmente migrar de JavaScript a TypeScript, recomiendo encarecidamente leer este libro porque algunos de sus capítulos finales hablan sobre la migración de JavaScript. Lo leí el año pasado y creo que es genial.

Permíteme continuar. Apenas estamos comenzando nuestro camino, en nuestro viaje a través del espectro de pruebas. No puedo hablar sobre aplicaciones de JavaScript sin mencionar la biblioteca de pruebas. Es absolutamente impresionante y soy un gran fanático de ella. Y esta cita que ha sido dicha por Ken C Dodds es básicamente todo lo que tienes que recordar cuando se trata de pruebas y elegir tu herramienta de pruebas. Cuanto más se parezcan tus pruebas a la forma en que se utiliza tu software, más confianza te pueden brindar. Mantén tus pruebas cerca de la experiencia de tus usuarios. Cada vez que intentes pensar en una nueva solución de pruebas, piensa si nos ayuda a enfatizar la experiencia que estamos entregando a nuestros usuarios.

Hay dos cosas que la biblioteca de pruebas de React hace increíblemente bien. En primer lugar, probar los detalles de implementación es difícil. La he estado usando durante bastante tiempo y honestamente no recuerdo cómo obtener el estado interno de un componente React con la biblioteca de pruebas de React. No tengo idea porque nunca necesito hacer eso. Y en segundo lugar, la API está diseñada de tal manera que nos ayuda a construir aplicaciones más accesibles. Así que para mostrarte un ejemplo, las consultas que son expuestas por las bibliotecas de pruebas básicamente, puedes obtener elementos por su rol, por texto, por texto alternativo. Por lo tanto, solo puedes interactuar con cosas que los usuarios realmente ven en la página. No hay detalles de implementación de pruebas. Cuando se trata de la biblioteca de pruebas de React, o de la biblioteca de pruebas en general, recomiendo encarecidamente jugar con testingplayground.com porque es una excelente manera de comprender qué tipo de consultas debes escribir. Para dar un ejemplo, imagina que tienes este correo electrónico muy pequeño con una etiqueta y un campo de entrada. Me gustaría probar eso. Así que voy a hacer una implementación un poco ingenua. Voy a agregar un ID de prueba y voy a obtener este elemento por su ID de prueba. Si lo ingresamos en el fondo de pruebas, vamos a ver que... Bien, hasta ahora todo bien. Va a funcionar, no me malinterpretes, pero podrías mejorarlo para obtener por rol con el fin de escribir mejores consultas, para escribir una mejor consulta para este componente.

De acuerdo, bastante justo. Así que voy a obtener este elemento por su rol, por el rol accesible de un cuadro de texto. Bien, hasta ahora, todo bien. Esto es increíble. Pero, y aquí está la idea clave de esto. Que podrías hacer la consulta un poco más específica agregando la opción de nombre, y esto requería agregar algo de marcado, porque tu elemento no está nombrado correctamente.

Entonces, aquí, el contexto de pruebas nos invita a escribir código más accesible, porque si agrego un poco de... Un poco de marcado adicional para hacer que este formulario sea más accesible, puedo obtener este elemento, esta entrada, por el rol accesible de un cuadro de texto y un nombre de dirección de correo electrónico. Y ahora he construido efectivamente un elemento de formulario accesible. Muy pequeño, eso sí, pero aún así, es accesible. Y también puedo probarlo. Así que he logrado tener éxito con dos objetivos, con, ya sabes, con una sola función, con una sola implementación de prueba.

Porque aquí está la cosa, todos deberían poder usar una aplicación web. La web es para todos y tus aplicaciones también deberían serlo. No deberías limitar tu base de usuarios por el hecho de que olvidaste preocuparte por la accesibilidad. Y esta charla no trata únicamente sobre accesibilidad y definitivamente no pretendo ser un experto cuando se trata de accesibilidad, pero recomiendo encarecidamente revisar este curso en echo.io, desarrollar aplicaciones web accesibles con React de Aaron Doyle. Y la mejor parte es que el curso es gratuito. Así que definitivamente no hay excusas para no revisarlo. Lo recomiendo encarecidamente.

Hablando de usuarios, la cosa es que a los usuarios no les importa tu código. No les importa si estás usando React, Angular, jQuery o cualquier otra cosa. Les importa los resultados que proporciona. Les importa la interfaz de usuario, la facilidad de uso y demás. Y ahí es donde entra en juego Cypress. Cypress es mi herramienta favorita para pruebas de extremo a extremo. Llevo usando Cypress como tres años y creo que es absolutamente increíble. Soy un gran fan de su interfaz de usuario, de su API y simplemente ver esas pruebas ejecutarse en el navegador es divertido para mí. Disfruto viendo los resultados de mis pruebas.

Y cuando se trata de Cypress, tengo dos cosas que me gustaría recomendar. En primer lugar, usar Cypress Testing Library porque si estás usando React Testing Library para probar tus componentes de React, si también estás usando Cypress Testing Library, obtienes dos beneficios.

En primer lugar, escribirás mejores consultas porque nuevamente se te animará a obtener elementos por roles accesibles y así sucesivamente. Y si no puedes obtener un elemento por un rol accesible, bueno, es hora de agregar uno. Y en segundo lugar, si vas a cambiar de escribir pruebas de integración o unidad a pruebas de extremo a extremo, habrá mucho menos cambio cognitivo porque no tendrás que pensar, `ok, estoy escribiendo una nueva prueba de unidad así que la API se ve así. Ahora estoy escribiendo una prueba de extremo a extremo así que hay una API completamente diferente. Todas esas cosas funcionan muy bien juntas.

En segundo lugar, Cypress ha agregado recientemente soporte para la API de Intercept y rápidamente se está convirtiendo en una de mis favoritas porque Intercept te permite tener un control total sobre el comportamiento de tus solicitudes HTTP. Y admite tanto REST como GraphQL porque, bueno, GraphQL es simplemente REST bajo el capó. No es REST, es HTTP bajo el capó cuando lo piensas. Todo son simplemente solicitudes HTTP. Y hay un par de cosas que la API de Intercept nos permite hacer. En primer lugar, por ejemplo, si tenemos una solicitud POST podemos afirmar que el cuerpo de esta solicitud incluirá una cadena. En segundo lugar, si estoy enviando una solicitud POST también puedo modificar esta solicitud antes de que se envíe al servidor. Así que tengo un control completo sobre la red, sobre las cosas que se enviarán a través de HTTP. En segundo lugar, si voy a enviar una solicitud a la API también puedo afirmar qué se incluirá en la respuesta de esa solicitud. Así que también puedo probar eso. Y Intercept te permite... Intercept se puede combinar fácilmente con todas las demás características y prácticas que Cypress proporciona. Por ejemplo, en este ejemplo puedo crear un comando personalizado que me permite detener las banderas de características en mi proyecto. Entonces, cada vez que llame a mi servicio de banderas de características podré obtener las banderas de características que voy a pasar a esta función. Y esta es una API altamente flexible y puedes hacer todo tipo de cosas con la API de Intercept. Recomiendo encarecidamente que lo revises.

Estamos acercándonos al usuario ahora. Está bastante cerca porque Cypress hace clic en botones escribe texto en campos de entrada y así sucesivamente. Pero los usuarios no van a usar nuestra aplicación de Cypress prueba de Cypress. Van a usar lo que vamos a lanzar. Así que tenemos que hablar sobre las prácticas para el ciclo posterior al lanzamiento porque bueno, nuestra aplicación tiene que ser rápida. Cada retraso de 100 milisegundos en el tiempo de carga del sitio web puede reducir las tasas de conversión en varios puntos porcentuales. Esto es absolutamente significativo para tu equipo, negocio emergente, y así sucesivamente. Y en segundo lugar, la mitad de tu base de usuarios abandonará una página si tarda más de tres segundos en cargarse. Pero aquí hay un problema.

¡Es rápido en mi máquina, ¿verdad? Estoy usando personalmente una MacBook Pro. Todo es rápido en mi máquina. Pero definitivamente no es la experiencia de la gran mayoría de tus usuarios. Hay un par de herramientas que nos ayudan cuando se trata de monitorear el rendimiento percibido de nuestros usuarios. Hay herramientas como Century, New Relic o Datadog. Y todas ellas, cuando se trata del desarrollo de JavaScript, hacen cosas bastante similares. Por ejemplo, Datadog te permite crear paneles de control para monitorear el rendimiento del frontend. Puedes crear paneles de control que monitorean el tiempo de la primera respuesta del servidor, el tiempo de la primera pintura de contenido, el tiempo de carga inicial, y así sucesivamente. Puedes medir todo tipo de métricas y comprender qué está sucediendo exactamente y qué experiencia estás brindando a tus clientes.

Además, herramientas como Datadog, Sentry y New Relic también te permiten monitorear los errores de JavaScript en producción, porque aunque estés utilizando los mejores tipos de TypeScript, es probable que tengas algunos problemas en tiempo de ejecución en producción. Siempre ocurren cosas como estas, como en Safari 9 o cualquier otro navegador. Con herramientas como estas, podrás comprender qué está sucediendo exactamente, investigar y solucionar el problema.

La forma definitiva de este espectro de pruebas no es tratar de empatizar con el usuario, sino convertirte en el usuario. En mi opinión, la mejor manera de hacerlo es utilizar tu propio producto. Esto se conoce como duck fooding en la comunidad de la industria tecnológica. No me gusta el término, pero lo usaré porque es ampliamente conocido en la industria. La idea es que las organizaciones utilicen su propio producto. Esta es una forma de probar los productos en un uso del mundo real. Para mí, esto es muy útil y muy importante, porque imagina que estás trabajando en una plataforma de entrega de alimentos. Si no quieres usar tu propio sitio web que has construido para pedir una pizza porque es lento, torpe y tienes que completar un formulario enorme cada vez, ¿por qué esperarías que tus usuarios lo usen? Si utilizas tu propio software, puedes empatizar con la experiencia que estás brindando a tus usuarios. Si algo te resulta molesto, es posible que también lo sea para otros. Entonces, ¿por qué no tomar la iniciativa y solucionarlo para ofrecer un software de mejor calidad?

Cuando se trata de medir la experiencia que estamos brindando a nuestros usuarios, debemos abordar el tema de las pruebas en producción. Y con pruebas en producción, no me refiero a desarrollar en amarillo, sino a lo que sea que queramos en producción. Pero debemos realizar pruebas en producción en ciertos aspectos, porque como dice Corey Quinn en Twitter, llamo a mi entorno de preparación teoría debido a la cantidad de cosas que funcionan en teoría pero no en producción. Quiero que cierres los ojos y pienses en tu entorno de preparación. Probablemente sea bastante diferente al de producción. Tienes una base de datos diferente. Tu base de datos es mucho más pequeña porque tienes cinco usuarios de prueba. Podrías tener una API para crear un usuario o agregar, no sé, $200 a su cuenta. Eso probablemente no es algo que tengas en producción. Y el entorno de preparación siempre es diferente al de producción.

Y por eso recomiendo encarecidamente el uso de herramientas como LaunchDarkly. LaunchDarkly es una herramienta de gestión de banderas de características que hace algunas cosas y las hace muy bien. En primer lugar, puedes definir diferentes banderas de características en producción y en la etapa de preparación previa a la producción, y así sucesivamente. Es bastante fácil de usar. Y en segundo lugar, si habilitas o deshabilitas la bandera de características, este cambio se propagará en cuestión de, no sé, segundos. Es muy rápido, es muy eficiente. Por ejemplo, puedes habilitar tu nueva y brillante característica en producción en tu cuenta de prueba. Puedes probarla, ver en producción si todo está bien, si está funcionando con tu API de producción. A continuación, puedes habilitarla solo para el 0.01% de tu base de usuarios y luego monitorear rápidamente qué diablos está sucediendo, si estoy viendo algún error. Luego, puedes habilitarla para el 50% de tu base de usuarios. Y por cierto, esta es también una excelente manera de realizar pruebas A-Btesting porque puedes habilitar una bandera de características solo para la mitad de la base de usuarios y luego implementarla para todos. Si quieres obtener más información sobre las pruebas en producción, te recomiendo encarecidamente esta charla de Talia Nasi. Está disponible en YouTube y profundiza mucho en los detalles o en cómo y por qué deberías hacer pruebas en producción.

Me gustaría cerrar esta charla expresando esta idea que en mi opinión, la calidad en el software proviene de ciclos de retroalimentación rápida. Porque si imaginas un ciclo de desarrollar, implementar, retroalimentar, repetir, si logras minimizar el tiempo que lleva completar todo este ciclo, puedes iterar mucho más rápido. Puedes lanzar software mucho mejor que responda mejor a los requisitos cambiantes de los usuarios, al mercado en constante cambio, y así sucesivamente.

Pero lo que quiero enfatizar aquí, es minimizar todo este ciclo, no solo la parte del desarrollador. No se trata de lanzar cualquier cosa a producción, porque entonces fallarás en la parte de retroalimentación. Porque tendrás problemas de producción, tendrás incidentes de producción, y no podrás avanzar hacia esta gran novedad, esta gran nueva característica, porque estarás atascado arreglando las cosas que se suponía que debías lanzar hace una semana.

En resumen, desarrollar software de alta calidad siempre es más rápido que solucionar problemas de producción a las 2 de la mañana. Y sé que hubo muchas cosas en esta charla, pero me gustaría dejarte con un último pensamiento final. Esto proviene de una filosofía de diseño de software de John Asterhaupt, quien dijo que, en general, la mejor manera de reducir los errores es hacer que el software sea más simple. Es algo en lo que debes pensar. Si encuentras que tu código es difícil de probar, considera lanzar menos código. Muchas gracias por escuchar.

Hola a todos. Así que, bien, bien. ¿Estás de acuerdo? Si tuvieras que, solo tuvieras la opción de escribir un tipo de prueba, ¿también sería de extremo a extremo? Absolutamente. Porque la idea es que si tuviera que agregar solo una prueba, me gustaría que la prueba se pareciera lo más posible a la experiencia que estamos entregando a nuestros usuarios. Y nuestros usuarios tienden a usar nuestra interfaz de usuario, hacer clic en botones, escribir texto y entradas. Y cuanto más podamos probar eso, mejor. Dicho esto, si me contrataran en una empresa y solo me dieran una prueba por proyecto, probablemente renunciaría en el acto, pero supongo que ese es otro tema.

Sí, por supuesto que es una pregunta hipotética, pero alimenta nuestro conocimiento de lo que la gente piensa y considera el tipo de prueba más importante para escribir. Así que eso es bueno saberlo. Por cierto, tengo que decir que me encanta el término `dogfooding` o `comer tu propia comida para perros`. Estoy totalmente de acuerdo con eso, y solía trabajar para un supermercado y también era cliente de ese supermercado. Y estaba muy feliz de trabajar en eso y de solucionar mis propios problemas, ¿verdad? Trabajé allí durante un año y nunca pude solucionar ninguno de mis problemas porque no soy el gerente de proyecto. Pero ser tu propio usuario es realmente importante. Así que eso es un buen punto. Y en mi opinión, eso supera cualquier herramienta de testing que puedas usar.

Ahora vamos a pasar a las preguntas de nuestra audiencia. Y la primera pregunta es de Martin. Y Martin quiere saber ¿cuál es un buen recurso para aprender sobre los roles y su accessibility? Hay muchos. En primer lugar, como mencioné en la charla, hay este increíble curso en Ekher.io sobre cómo construir aplicaciones React accesibles. Y aunque no estés usando React, te recomiendo encarecidamente que eches un vistazo a este curso, porque habla sobre muchas prácticas que son completamente independientes del marco de trabajo. En segundo lugar, te recomiendo seguir y leer todo lo escrito por mi amiga, Lindsay Kopacz, quien también ha escrito un libro sobre accessibility. Y es absolutamente increíble. He aprendido mucho leyendo todo lo que ha escrito y lo recomiendo encarecidamente. Y en segundo lugar, creo que, ya sabes, la accessibility es un tema muy amplio y es muy, diría yo, ridículo poder tener una comprensión completa de todos los diferentes aspectos de la accessibility, porque hay mucho de eso. Entonces, lo que probablemente haría y recomendaría encarecidamente es comenzar por lo más fácil, como intentar usar tu sitio web con un teclado. Y luego, si no puedes hacerlo, descubre qué puedes agregar a tu aplicación para mejorarlo. Porque leer toda la documentation, probablemente no sea la forma más útil de utilizar tu tiempo. Pero si mejoras tus propios problemas, volviendo al `dogfooding`, entonces podrás mejorar la accessibility de tu aplicación. Sí, es un punto muy importante que también mencionar en una conferencia de testing, si me preguntas, es que la accessibility siempre debe ser una prioridad, por supuesto.

La siguiente pregunta es de Yanni Kolev.

¿Qué opciones consideras más importantes en Prettier? Creo que los puntos y comas. Prettier tiene algunas opciones, pero para mí, el mayor valor de Prettier es no tener que pensar en las opciones, como el hecho de poder agregar Prettier a un proyecto y ya no tener discusiones sobre cómo formatear este tipo de función o si debemos agregar una coma al final de este objeto JSON o no, todas esas discusiones desaparecen por completo. Así que no solo desde la perspectiva de testing, como mencioné en la charla, es un ciclo de retroalimentación mucho más rápido, sino también desde la experiencia de un desarrollador que quiere llevar las cosas a producción, no tener esas discusiones interminables en Kotlin parece que acelerará todo. En mi humilde opinión, tal vez esto sea una opinión controvertida, no lo sé. No veo ninguna razón para no usar Prettier. Sí. Y no deberías configurar nada. Solo usa los valores predeterminados y todo funcionará sin problemas. Hombre. Estoy dispuesto a morir por esto. Sí. La siguiente pregunta es de, espero pronunciar esto correctamente, Shuganda, ¿recomendarías Cypress en lugar de Protractor para aplicaciones basadas en Angular? Soy un gran fanático de Cypress y lo he estado usando durante los últimos años. Y debo admitir que tan pronto como encontré Cypress, ya no prestaba mucha atención a otras herramientas. Así que mi opinión personal sería simplemente usar Cypress, pero esto es solo una idea general. Usa lo que resuelva tus problemas y no lo que sea más popular o resuelva los problemas de otra persona. Tus problemas son tuyos para resolver. Dicho esto, me encanta Cypress. Cypress es increíble. Y no te están pagando para decir esto, ¿verdad? No, supongo que eres más que bienvenido. Bueno, le preguntaremos a Glab mañana. Tenemos tiempo para una pregunta rápida, respuesta rápida. De Ciderman Criederman, ¿en qué tipo de pruebas pasas la mayor parte del tiempo escribiendo en la pirámide/trofeo/colmena? Pruebas de integración, la gran mayoría. Como debería ser. De acuerdo, genial. Bueno, hay más preguntas de la audiencia, pero si las personas que están haciendo preguntas quieren hacértelas, pueden hacerlo en tu sala de oradores porque no tenemos más tiempo para hacer preguntas. Así que quiero agradecerte por estar aquí con nosotros hoy. Sé que tenías mucho en tu plato. Puedes salir ahora mismo en Polonia, en todas partes. Es increíble, pero sí, gracias. Gracias por unirte y espero verte de nuevo pronto. Muy bien, salud a todos. Voy a la sala de oradores. Adiós.