5 Hábitos para Tratar tu Código de Pruebas como Código de Producción

Hola a todos. Hoy voy a hablar sobre los cinco hábitos para tratar tu código de prueba como lo harías con el código de producción. Así que, en primer lugar, ¿quién soy yo? Mi nombre es David Burns o como la mayoría de la gente me conoce, tester automatizado. Soy el responsable de la Oficina de Programas de Código Abierto en Browserstack. Soy el presidente del grupo de trabajo de pruebas de navegadores y herramientas del W3C. Soy un colaborador de Selenium y Nightwatch JS. Llevo tiempo en esta industria. Y espero que al final del día, puedas llevar algo contigo y ver cómo puedes reorganizar todo lo que haces en el trabajo para facilitar tu vida.

Aquí está nuestra agenda. Voy a analizar cómo las personas tienden a ver sus pruebas en los proyectos, cómo podemos descomponer las pruebas para que sean manejables, mantenibles y menos propensas a errores. Esa es la parte más importante. Cómo tratar tu código de prueba como código de producción. Entonces, qué hacemos con la última parte y cómo mejorar tus herramientas y en realidad por qué esto es importante. Te sorprenderás. Así que empecemos y veamos a dónde llegamos.

Ahora, he estado trabajando en pruebas durante muchos, muchos años y tiendo a ver cómo las personas ven las pruebas desde diferentes perspectivas. Y si lo vemos de la manera teórica, así es como deberían hacerlo las personas. En la parte inferior, tenemos aquí la pirámide de pruebas. En la parte inferior, tenemos las pruebas unitarias. La razón por la que eso es importante es porque la razón por la que es más amplia es que siempre debería haber muchas más de ellas que cualquier otro tipo de pruebas en nuestro código de prueba. Luego tenemos las pruebas de servicio. Estas son nuestras pruebas de integración. Estas son todas como si las pruebas unitarias fueran pequeñas, las pruebas de servicio tienden a ser medianas y comienzan a cerrar las brechas entre todos nuestros pequeños componentes de código o áreas atómicas de código. Y nos acerca a la siguiente parte, que son nuestras pruebas de interfaz de usuario. Ahora, una de las cosas que no incluí aquí es la prueba manual. Por lo general, tiendo a hablar sobre las pruebas automatizadas, pero esto no significa que menosprecie las pruebas manuales. Y si observas las flechas en el lateral, verás que en el lado izquierdo, a medida que miro la pantalla, hay más aislamiento y más integración. A medida que subes, necesitarás más integración y menos aislamiento. Sin embargo, el inconveniente de agregar más integración es que las cosas se volverán más lentas. Esto es simplemente ciencia de la computación, ¿verdad? Cuanto más código tenga que procesarse, más lento será, ¿verdad? Si haces un bucle dentro de otro bucle, sabes que será más lento que un solo bucle tratando de encontrar algo. Idealmente, debemos intentar hacer pruebas súper rápidas y muchas menos pruebas lentas. Desafortunadamente, especialmente por lo que veo, y aprecio que pueda haber mucho sesgo, después de haber trabajado en Selenium y NightwatchJS durante muchos, muchos años, es que las personas hacen pruebas unitarias. Estas generalmente son realizadas por tus desarrolladores, y se hacen con jest, Karma o cosas así, y las personas ponen mucho esfuerzo en ellas. Luego comenzarás a tener algunas pruebas de servicio o estas pruebas de integración, y así tomé mi imagen aquí del trabajo de Martin Fowler, y la he reorganizado un poco. Luego, especialmente ahora que veo esto en BrowserStack y hablo con los clientes, y cuando estaba en Mozilla, hablando con usuarios de Selenium, las personas tienden a arrojar todo, y quiero decir todo, a sus pruebas unitarias. Las llenarían, pondrían toneladas de pruebas, y luego, poco a poco, las pruebas se volverían inmantenibles.

Un desarrollador realizaría un cambio en la interfaz de usuario. Un diseñador ayudaría, y de repente, una gran cantidad de pruebas comenzarían a fallar. Y luego, obviamente, ¿a quién se culpa? A la herramienta de testing. No a las personas que han diseñado el código o las pruebas. Ninguna de esas personas. Es puramente culpa del marco de pruebas. Tú y yo sabemos que eso no es correcto, pero generalmente así es como reacciona la gente, ¿de acuerdo?

Y se dedica mucho esfuerzo a las pruebas de interfaz de usuario. Y de repente, dicen: No tengo tiempo para escribir pruebas de interfaz de usuario. Tengo que hacer estas pruebas manuales para poder entender lo que tengo que hacer. Y las construyen, y las construyen, y las construyen. Y luego intentan escalar horizontalmente porque sus pruebas de interfaz de usuario tardan un día en ejecutarse. Todos sabemos que idealmente la integración continua debería estar lista en 10 minutos, ¿verdad? Ese es el estándar de oro. Siempre intenta que todas tus pruebas se realicen en 10 minutos para tener un ciclo de retroalimentación rápido porque no sé tú, pero cuando escribo código, no siempre funciona. Lo admito. Escribo mucho código. Escribo muchos errores. Afortunadamente, suelo escribir muchas pruebas para acompañarlo. Y a veces funcionan en mi máquina y luego dejan de funcionar en la integración continua porque hay ciertas suposiciones. Pero necesitamos ese estándar de oro de pruebas realmente rápidas. Y si estamos acumulando todo en el área de la interfaz de usuario, entonces será realmente, realmente lento.

Entonces, ¿cómo podemos solucionar eso? Bueno, hagamos nuestras pruebas mucho más modulares. Conocemos las pruebas pequeñas, ¿verdad, o pruebas unitarias? Conocemos las pruebas de integración o pruebas medianas. Y tenemos estas pruebas de extremo a extremo o pruebas grandes. El problema es que no siempre se necesitan pruebas de extremo a extremo. Sabemos que si hay un formulario, puedes probar ese formulario de forma aislada. No necesita ser todo un flujo de trabajo completo. Puedes construir estas cosas, especialmente si estás trabajando con tu equipo de front-end o construyendo componentes modularizados para avanzar. Y así, necesitamos elegir la prueba adecuada, al igual que elegir la arquitectura adecuada. Sé, por haber trabajado con muchas personas en la escritura de pruebas, que si estás escribiendo código, no vas a tener un archivo monolítico y luego enviarlo a producción.

Y estoy diciendo que este no es tu código ofuscado y minificado, ¿verdad?, obviamente eso será un archivo. Pero cuando estamos llegando a ese punto, sabes que si quieres encontrar ciertas cosas, cómo estructurar tu código. Desafortunadamente, la gente no siempre hace eso. Con sus pruebas, no saben cómo arquitecturarlas. Y esto puede parecer controvertido, pero es por eso que es importante que tus SDETs o tus ingenieros de desarrollo de software en pruebas, se tomen el tiempo para saber lo que están haciendo. No les asignes a un junior y digas, este es tu problema. No les asignes a un tester exploratorio. Trata a tus SDETs como tratarías a tus ingenieros de software, desde el pago hasta el reconocimiento, y verás grandes mejoras en cómo se formatea tu código y tus pruebas.

Entonces, sabemos que no vamos a crear monolitos en nuestro código de producción cuando lo estamos escribiendo todo antes de que se integre en nuestro sistema de construcción. Así que no lo hagas cuando estés en tu entorno de pruebas.

Divide tus pruebas. ¿Cada buena presentación es un buen meme, verdad? Divide tus pruebas. Si estás probando partes modulares pequeñas, divídelas. Asegúrate de que puedas ejecutar cada prueba individualmente, al igual que lo harías si estuvieras dividiendo tu código de producción, ¿verdad? La gente dice, sí, sí, puedo dividir mi código. Sé cómo descomponer esto, ¿verdad? Dices lo mismo para las pruebas y ellos dicen, es una prueba, ¿por qué importa? Importa. De verdad, importa.

Y por eso necesitamos adoptar esta mentalidad de que, cuando estás escribiendo código, estás escribiendo código, ya sea una prueba automatizada o código de producción, ¿verdad? O cualquier cosa intermedia. El código es código. Tus estetas son ingenieros. Ellos escriben código. Tus ingenieros de software, ellos escriben código. Son exactamente lo mismo. Miran los problemas ligeramente de manera diferente, pero siguen mirando el problema. Así que es importante asegurarnos de que cuando estemos dividiendo estas cosas en partes individuales, lo hagamos de manera significativa.

Así que hemos hablado de esto, donde tenemos nuestras pruebas unitarias, nuestras pruebas de servicio, pero esa parte grande y voluminosa de la interfaz de usuario, podemos descomponerla aún más. No necesitamos una prueba de extremo a extremo completa para nuestras pruebas de interfaz de usuario. Sí, es posible que necesitemos un navegador, y es importante asegurarnos de que probamos en todos los navegadores que utilizan nuestros usuarios. Si vas a probar en Chrome, prueba en Chrome, Chromium va a reaccionar ligeramente diferente. Así que si pruebas en Chromium, no siempre obtendrás la misma experiencia final que un usuario de Edge, o un usuario de Chrome, o un usuario de Brave, o un usuario de Opera o Vivaldi, ¿verdad? Es el mismo navegador en el fondo para el motor, pero no siempre te dará el mismo resultado cuando estés moviendo las cosas debido a la forma en que lo configuran y lo envían. Lo mismo ocurre al usar WebKit. WebKit puede ser la herramienta y el motor subyacente para Safari, pero hay momentos en los que Safari actuará de manera muy diferente a WebKit, y actuará de manera muy diferente a Safari en iOS. Así que asegúrate siempre de que cuando estemos dividiendo estas cosas, las dividamos y luego probemos donde van nuestros usuarios finales. Porque de esa manera, podemos saber que hemos hecho el trabajo correcto.

Ahora, al dividir las cosas en partes ligeramente más manejables, eliminaremos la inestabilidad. Cuanto más pequeñas sean tus pruebas, menos inestables serán. Seguro que todos han intentado escribir pruebas de extremo a extremo, y muchas veces, necesitas alinear muchas cosas para que funcione. Tu base de datos necesita estar configurada, tu middleware necesita estar configurado, tu frontend necesita estar funcionando, y cada vez que haces algo, necesita poder pasar por todas estas capas y luego volver. Y como estamos hablando de JavaScript, todo es asíncrono. Así que necesitas alinear muchas cosas para que las cosas funcionen.

A veces funcionará y tendrás medios para probar cosas, así que al trabajar en NightwatchJS, que se basa en Selenium, hace todo el autowaiting para que puedas saber cuándo están las cosas. Pero necesitas saber que esa cosa estará ahí. Y por eso necesitamos descomponer las cosas, hacerlas más pequeñas, y vamos a descomponer las pruebas de interfaz de usuario. Porque las pruebas de interfaz de usuario, las pruebas de extremo a extremo tardan demasiado en ejecutarse. ¿De acuerdo? Seamos claros. No es suficiente.

Entonces, ¿cómo lo vamos a dividir? Sigo diciéndolo, necesitamos dividirlo, pero ¿cómo vamos a poder dividirlo en realidad? Tengo un ejemplo. Y vamos a echarle un vistazo. Así que aquí... Aquí... Aquí tienes una prueba pequeña, ¿de acuerdo? Es realmente, realmente pequeña. Y recomiendo a todos los que escriben pruebas, especialmente pruebas de extremo a extremo, que sus pruebas hagan como máximo tres cosas. Comienzan desde un buen punto conocido, hacen una cosa, pero una cosa muy bien con una afirmación, si no hace una afirmación, no es una prueba útil. Y luego sabe a dónde regresar. Y así, en este caso, tengo aquí un poco de código de demostración. Y déjame hacerlo realmente grande. Y voy a hacer zoom, para que puedas leerlo. Aquí tenemos algunas pruebas de componentes. Tenemos un componente React que voy a cargar. Y si quieres ver cómo se ve, simplemente se ve como un componente React estándar. Este es un formulario para una lista de tareas. Así que toma todo, tiene sus entradas, tiene algún cambio de estado y tiene el botón de envío. Muy, muy simple, ¿verdad? Y todos pueden ver qué es, pueden trabajar con ello. Todos han trabajado con React, así que estoy bastante seguro de que nada de esto te sorprende. Pero lo importante aquí es que podemos escribir la prueba para poder, como una especie de, cargar un componente. Cargar un componente, en este caso, podemos esperar que sea visible, que vamos a trabajar con él.

Ahora, he hecho algo muy simple aquí, pero podríamos simplemente descomponerlo y hacer cosas. Así que, como es de noche, esta es una prueba de night watch, es muy simple. Tiene una API fluida agradable para que puedas trabajar con ella. Y puedes hacer más cosas. Así que podrías hacer, esperar al navegador, encontrar el elemento, componente, y descomponerlo y luego ingresar en él, si quieres escribir algo, puedes establecer el valor, Me encanta el queso, porque sí. Y eso funcionaría.

Podrás interactuar, y ahora en lugar de una prueba de extremo a extremo completa, no vamos a comprobar que podamos enviar todo hasta la database. Esas pruebas siguen siendo útiles, pero necesitamos menos de ellas y muchas más de este tipo de pruebas de componentes pequeñas y modularizadas. Y podemos simplemente usar los mismos componentes que hemos estado usando antes. Así que es realmente, realmente simple.

Otra cosa en la que creo que es importante que las personas se centren es asegurarse de que una vez que hayas hecho que tu prueba funcione, mantengas todos tus elementos actualizados, todos tus paquetes de npm. Así que en este caso, como ejemplo, se lanzó un nuevo controlador Gecko y una nueva versión de Nightwatch. npm update debe usarse en todas tus dependencias de prueba todo el tiempo, mantenlo actualizado regularmente. Idealmente, configura un bot para hacerlo. Esto es solo trabajo ocupado para una persona. Y por eso deberías usar bots cuando sea posible. Y llegaremos a eso en un segundo.

Pero asegúrate de que al menos ejecutes npm updated una vez por sprint en tu trabajo, para que puedas mantener las cosas actualizadas. Y puedes comenzar a usar nuevas características de inmediato. Con Nightwatch, enviamos Selenium bajo el capó. Y permitimos a las personas hacer cosas realmente geniales como la intercepción de red, manejo básico de autenticación, mensajes de error de la consola de JavaScript, captura para que puedas fallar las pruebas si tu JavaScript no es muy bueno. O si quieres buscar ciertas mutaciones en la página, puedes configurarlo todo y ser capaz de hacerlo. Y esas cosas salen regularmente y se actualizan. Y es importante que mantengas tus dependencias de prueba tan actualizadas como las de producción. No digas, oh, es una prueba. No necesita ser actualizada. Hay buenas razones por las que se actualizan regularmente. Y este es un buen ejemplo.

Estas son las versiones de Nightwatch que existen. Y tenemos personas en todo el espectro. Y he tomado solo un pequeño fragmento de nuestra base de usuarios. Y es importante que mantengas las cosas actualizadas. Entiendo que algunos proyectos nunca necesitan ser actualizados. Pero si no estás actualizando el código de producción, entonces no actualizarás el código de prueba. Si es así, está bien, pero si estás haciendo actualizaciones en tus dependencias en tu código de producción, asegúrate de hacerlo también en tu código de prueba. Es importante.

Y finalmente, ten tooling que te mantenga en flujo. Yo uso VS Code todo el tiempo. Y en el momento en que tengo que salir de VS Code, sé que para mí, puedo distraerme fácilmente. Así que trata de encontrar tooling que te mantenga en flujo, que te mantenga trabajando, que te mantenga en donde necesitas estar. Como dije, trabajo con Nightwatch. Nightwatch tiene una extensión de VS Code para poder ejecutar pruebas. Todo lo que necesito hacer es hacer clic en un botón. Me muevo a mis pruebas, puedo ejecutarlas. Puedo ejecutarlas en diferentes entornos. Puedo ejecutar mis pruebas de componentes. Puedo ejecutar todo desde donde estoy. En el momento en que necesitas aprender nuevos comandos, nuevas cosas, te saca del flujo. Así que trata de encontrar esa herramienta que te mantenga donde estás. Te ayuda a probar tus componentes desde el principio y luego te mantiene en flujo. Así fluye cuando estás trabajando, estás concentrado, estás trabajando duro y todo está bien. Así que sigue adelante.

Y eso es todo, amigos. Espero que hayan encontrado esto realmente útil. Como dije antes, mi nombre es David Burns. Soy el probador automatizado. Trabajo en Nightwatch y Selenium. Y si tienen alguna pregunta, pueden encontrarme en las redes sociales o en Discord o Slack. Y siempre estoy dispuesto a ayudar. Gracias.

Entonces tenían una pregunta, que le hicimos al público antes de su charla, es como, ¿hacen otras cosas de testing? Las respuestas son como las pruebas de regresión visual están en un 62%, y las pruebas de accesibilidad están en un 38%, y las pruebas de rendimiento están en un 37%. Entonces, ¿qué piensan de estos resultados? Es más o menos lo que esperaba. Es algo en lo que he estado investigando recientemente, y tenía mucha curiosidad por lo que la gente estaría haciendo. Creo que las pruebas de regresión visual son bastante populares en este momento. Así que sí, coincide con lo que esperaba. Así que eso es bueno. Al menos mi intuición estaba en lo correcto allí. Genial. Sería bueno si la gente comenzara a hacer más pruebas de accesibilidad también. Definitivamente. Sin duda. Sí. Así que tenemos preguntas para ustedes. Entonces, la primera pregunta es, ¿con qué componentes trabajan primero al testing? Supongo, sí. ¿Con qué componentes trabajan primero? Sí. En este caso, creo que es cómo la gente lo descompone. ¿Verdad? Entonces, ya saben, con su, cuando pasan al código de producción, ¿verdad?, tratan de ir por la pieza más pequeña. Y así, lo que puedan lograr hasta ese punto es el área en la que creo que deben enfocarse. Y así que si pueden, como sé que mucha gente mira cosas como storybook o lo que sea, ¿verdad?, se trata de tratar el código, su código de prueba como código de producción, ¿verdad? Y así que si van a hacer pruebas de componentes, hagan eso. Y miran sus componentes, los descomponen, y luego los extienden hacia afuera. Así es como suelo hacerlo. No tengo un área en la que me enfoque, pero encuentro la que es más importante.

La mejor lógica empresarial, cosas así. Sí, genial. Sí, definitivamente. Entonces, Epster pregunta cuáles son las buenas prácticas para las pruebas de instantáneas. Tengo sentimientos encontrados al respecto y muchos de ellos realmente entran en conflicto, lo cual me parece bastante interesante. Volviendo a las instantáneas, siempre debes intentar que haga lo que crees que va a hacer y mantenerlo así, ¿verdad? Y luego, algo en lo que he estado trabajando recientemente es tratar de extender algunos de los proyectos en los que estoy trabajando para que funcionen con NX, la herramienta de monorepo. Eso utiliza muchas pruebas de instantáneas. Y hay momentos en los que simplemente tengo que concentrarme en esto, hacerlo bien, y luego hay momentos en los que simplemente digo, voy a reescribir todo y anular las instantáneas. Y en cierto modo, y así pierdo rápidamente el valor en ello. Pero al mismo tiempo, también puedo usarlo para darme cuenta de que he cometido un gran error. Y así es como suelo hacerlo. Es lo mismo con las pruebas visuales. Tomo mis instantáneas y a veces es como, en realidad solo quiero reescribir todo y desecharlo todo porque es simplemente frustrante. Y ahí es donde lo encuentro útil. Y a veces lo encuentro frustrante. Así que tengo estas cosas contradictorias en mi cabeza. Así que es difícil.

Sí, quiero decir, ciertamente para mí, cuando escucho por primera vez pruebas de instantáneas, en realidad solo pienso en las pruebas de instantáneas, que solíamos hacer para React. Y así que cuando comenzamos, pensamos, sí, deberíamos hacer pruebas de instantáneas para todo. Y pronto se vuelve demasiado pesado de mantener porque estás haciendo cualquier cambio. Y simplemente sigues adelante sin pensar y ejecutas hyphen U y actualizas la instantánea. Como la mayoría de las personas, no creo eso. Sí, así que no hay práctica en la que las personas realmente vayan y vean si la instantánea se rompió, ¿por qué se rompió? Entonces, tal vez falsifica el proceso real, una razón para las pruebas de instantáneas. Pero sí, nuevamente, razones contradictorias, como dijiste.

Entonces hay otra pregunta. ¿Por qué hacer pruebas de componentes cuando se pueden hacer pruebas de extremo a extremo para verificar las cosas? Sí, eso es lo que más me gusta en este momento. Al principio, dije que debes descomponer tu código, descomponer todo. Así avanzas en la menor cantidad de partes. Correcto. Lo que me gusta de hacer eso y luego tratar tu código como producción y luego ir, lo que ha llevado a esta creencia en las pruebas de componentes, en la que estoy 100% de acuerdo, es la idea de que puedes simplemente ir, voy a hacer las partes pequeñas, asegurarme de que esta pequeña parte sea correcta, lo cual será súper rápido. Porque, habiendo trabajado en navegadores, lo que siempre noté es que a muchas personas les cuesta entender conceptos como la asincronía. Incluso si trabajas con JavaScript todos los días, aún hay momentos en los que JavaScript simplemente dice. Pero solo voy a responder ahora. Así que has estado esperando, o has escrito este infierno de devolución de llamada, o tienes estas promesas anidadas, y piensas, bueno, esto no va a funcionar. Y así lo estamos descomponiendo. Como lo harías en producción, asegurándote de que tus pruebas estén en archivos específicos, tus pruebas estén haciendo lo mismo en los puntos correctos. Y no te estás enfocando en demasiadas cosas diferentes, entonces llegas a esta capacidad de ejecutarlas más rápido, súper rápido. Y luego, si quieres hacer tus pruebas de accesibilidad, tus pruebas visuales, serán aún más rápidas que si hicieras una página completa para hacer tu prueba. Así que todo se trata de la velocidad de esa manera. Gracias. Así que tengo otra pregunta, que es como hablaste de las herramientas, ¿verdad? Como, deberíamos mantener nuestras herramientas que nos mantienen en flujo. ¿Tienes alguna preferencia de herramientas? ¿Qué tipo de herramientas usas cuando se trata de pruebas de UI o integración, y así sucesivamente? En cuanto a las herramientas, no uso demasiado. Soy un desarrollador de Visual Code, desarrollo en Visual Code. No desarrollo Visual Code. Y encuentro todas las cosas que necesito que son importantes para mantenerme en ese espacio. Encuentro las extensiones que hacen esos trabajos por mí, ¿verdad? En el momento en que siento que necesito salir de algo, entonces veo poco valor. Así que no tengo una herramienta específica, pero es la herramienta que encuentro útil para la tarea en este momento. Y luego trato de optimizar en torno a eso, y así, pueden ser cosas simples. Así que simplemente aprender a no usar el mouse, navegar solo con el teclado si puedes, porque así obtienes mucha más velocidad, mucho más flujo y cosas así. Y también puedes probar la accesibilidad. Exactamente. Definitivamente. Sí. Muchas gracias, David, por unirte hoy. Nuevamente, fue una gran charla y por estar allí para las preguntas y respuestas. A pesar de todos los problemas. Gracias. No, gracias. Gracias a todos. Espero que lo hayan disfrutado. Si tienen alguna otra pregunta, siempre pueden enviarme un mensaje en Twitter o algo así, así que estaré encantado de ayudar.