Envío de aplicaciones JS de alta calidad con confianza

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Enviar código sin errores a producción es (obviamente) imposible, pero aún así, nuestros usuarios merecen la mejor experiencia que podemos brindarles. No solo eso, si ganamos confianza en la forma en que construimos nuestro software, podemos dormir mejor por la noche sabiendo que no explotará en medio de la noche.


En esta charla vamos a cubrir algo que llamo "El Espectro de Pruebas" - un conjunto de herramientas, prácticas y mentalidad para enviar código de alta calidad a producción. Desde prettier hasta monitoreo, ¡evitemos juntos tu próximo incidente de producción!

This talk has been presented at TestJS Summit - January, 2021, check out the latest edition of this JavaScript Conference.

FAQ

Una empresa con casi $400 millones en activos se declaró en bancarrota en 45 minutos debido a una implementación fallida, donde un servidor antiguo no fue actualizado y causó problemas severos.

La calidad del software es crucial no solo para ser buenos ingenieros, sino porque puede determinar el éxito o el fracaso de un negocio, como demostró el caso de la empresa que perdió $460 millones en 45 minutos.

Tomasz Hokomer recomienda usar TypeScript, especialmente en modo estricto, porque los tipos estáticos ayudan a eliminar ciertos tipos de errores, como 'undefined no es una función'.

Hokomer sugiere un enfoque de espectro de pruebas que combina diferentes herramientas y prácticas, desde las cercanas al desarrollador hasta las que simulan la experiencia del usuario, como Prettier y TypeScript.

Recomienda usar herramientas como Cypress y Testing Library, que permiten escribir pruebas que se asemejan más a cómo los usuarios reales interactúan con el software.

Hokomer enfatiza la importancia de construir aplicaciones accesibles y recomienda integrar pruebas que aseguren la accesibilidad, como las que proporciona la biblioteca de pruebas de React.

Las pruebas en producción son cruciales porque el entorno de producción puede diferir significativamente del de pruebas, afectando el rendimiento y la estabilidad del software.

Hokomer aconseja usar su propio producto ('dogfooding') para entender mejor y mejorar la experiencia del usuario, asegurando que el software sea efectivo y agradable de usar.

Tomasz Łakomy
Tomasz Łakomy
29 min
15 Jun, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla de hoy destaca la importancia de la calidad del software y su impacto en los negocios. Se enfatiza el uso de diferentes herramientas y prácticas para mejorar la calidad del software. La charla aborda temas como las pruebas con TypeScript y React Testing Library, la accesibilidad, Cypress para pruebas de extremo a extremo, escribir mejores consultas, monitorear el rendimiento, usar banderas de características con LaunchDarkly y el valor de Prettier. La idea principal es que desarrollar software de alta calidad con ciclos de retroalimentación rápidos y simplicidad es crucial para el éxito.

1. Shipping High Quality JavaScript Apps

Short description:

Hoy quiero hablar sobre cómo enviar aplicaciones JavaScript de alta calidad con confianza. Comenzaré con la historia de una empresa que se declaró en bancarrota en 45 minutos debido a una implementación fallida. Esto resalta la importancia de la calidad del software y su impacto en los negocios. No hay una solución única para mejorar la calidad del software, como se indica en el artículo 'No hay bala de plata'. Requiere una combinación de diferentes herramientas y prácticas, representadas por el espectro de pruebas.

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.

Read also

2. Herramientas para Calidad y Pruebas

Short description:

Existen herramientas y prácticas que ayudan a mejorar la calidad del software. Las pruebas son una combinación de estas herramientas y prácticas. Prettier, aunque no es una herramienta de pruebas típica, ayuda a minimizar los ciclos del editor y permite una iteración más rápida. TypeScript, con sus tipos estáticos, elimina ciertos errores y también ayuda a minimizar los ciclos del editor. Se recomienda usar TypeScript en modo estricto para mejorar la calidad del código.

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.

3. Pruebas con TypeScript y React Testing Library

Short description:

Cuando se trata de TypeScript, es algo fácil para proyectos nuevos pero muy difícil para proyectos heredados. La biblioteca de pruebas nos ayuda a construir aplicaciones más accesibles y se enfoca en probar la experiencia de los usuarios. Las consultas expuestas por las bibliotecas de pruebas permiten interactuar con elementos visibles en la página. Por ejemplo, obtener elementos por su rol, texto o texto alternativo. Se recomienda la biblioteca de pruebas de React y testingplayground.com es una excelente herramienta para comprender cómo escribir consultas.

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.

4. Accesibilidad, Cypress y Pruebas

Short description:

Cuando se trata de accesibilidad, agregar un poco de marcado adicional puede hacer que un formulario sea más accesible. Todos deberían poder usar una aplicación web, por lo que es importante preocuparse por la accesibilidad. Recomiendo echar un vistazo al curso 'Desarrollar aplicaciones web accesibles con React' de Aaron Doyle. A los usuarios les importan los resultados y la interfaz de usuario, y ahí es donde entra en juego Cypress. Cypress es mi herramienta favorita para pruebas de extremo a extremo, y recomiendo usar Cypress Testing Library para probar componentes de React.

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.

5. Writing Better Queries and Cypress's Intercept API

Short description:

En primer lugar, escribir mejores consultas al obtener elementos por roles accesibles. Cambiar de pruebas de integración/unidad a pruebas de extremo a extremo con menos cambio cognitivo. La API de Intercept de Cypress proporciona un control total sobre las solicitudes HTTP, admitiendo REST y GraphQL. Afirmar y modificar los cuerpos de las solicitudes, probar los contenidos de las respuestas. Se puede combinar fácilmente con otras características de Cypress. Prácticas para el ciclo posterior al lanzamiento: la velocidad de la aplicación es crucial, los retrasos afectan las tasas de conversión, los usuarios abandonan las páginas de carga lenta.

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.

6. Monitoring Performance and Testing in Production

Short description:

Es importante monitorear el rendimiento percibido de los usuarios utilizando herramientas como Century, New Relic o Datadog. Estas herramientas te permiten crear paneles de control para monitorear el rendimiento del frontend y los errores de JavaScript en producción. Para comprender realmente la experiencia del usuario, se recomienda utilizar tu propio producto, una práctica conocida como duck fooding. Al usar tu propio software, puedes empatizar con la experiencia del usuario y realizar mejoras. La prueba en producción es necesaria para tener en cuenta las diferencias entre los entornos de preparación y producción.

¡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.

7. Using LaunchDarkly for Feature Flags

Short description:

Recomiendo encarecidamente el uso de LaunchDarkly, una herramienta de gestión de banderas de características. Te permite definir diferentes banderas de características en producción y en la etapa de preparación previa a la producción. Puedes habilitar o deshabilitar la bandera de características y el cambio se propaga rápidamente. Es excelente para probar nuevas características en producción y realizar pruebas A-B. Para obtener más información, mira la charla de Talia Nasi sobre pruebas en 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.

8. Closing Thoughts on High-Quality Software

Short description:

La calidad en el software proviene de ciclos de retroalimentación rápida. Minimizar todo el ciclo, no solo la parte del desarrollador, es crucial. Desarrollar software de alta calidad siempre es más rápido que solucionar problemas de producción a las 2 de la mañana. La mejor manera de reducir los errores es hacer que el software sea más simple.

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.

QnA

End-to-End Testing and Accessibility Resources

Short description:

Si tuvieras que escribir un tipo de prueba, sería de extremo a extremo. Ser tu propio usuario es importante y supera cualquier herramienta de prueba. Un buen recurso para aprender sobre roles y accesibilidad es el curso en Ekher.io y los escritos de Lindsay Kopacz. Comienza con lo más fácil, como usar tu sitio web con un teclado.

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.

El Valor de Prettier y la Configuración Predeterminada

Short description:

El mayor valor de Prettier es no tener que pensar en las opciones de formato. Elimina las discusiones interminables y acelera el desarrollo. Se recomienda usar la configuración predeterminada.

¿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.

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Todos pueden escribir pruebas fácilmente
TestJS Summit 2023TestJS Summit 2023
21 min
Todos pueden escribir pruebas fácilmente
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.