No se trata de tu Biblioteca de Asertos

Hola, gracias por acompañarme. Mi nombre es Mark Rubin y en mi tiempo libre, mantengo un ejecutor de pruebas de Node.js llamado Ava. Tal vez hayas oído hablar de él como se insinúa en el título de esta charla. No estoy aquí para hablar realmente de Ava, pero definitivamente deberías echarle un vistazo. Ahora, en mi trabajo diario, trabajo como ingeniero de productos principal en Monolith, que es un proveedor de servicios financieros en el espacio de las criptomonedas en el Reino Unido y Europa. Tampoco estoy aquí para hablar de eso, pero por supuesto que deberías echarle un vistazo. Esta no es una charla sobre ejecutores de pruebas, ni sobre criptomonedas o cómo escribo pruebas en la oficina. En cambio, es una charla sobre lo que creo que debemos esforzarnos en nuestra profesión y el papel que pueden desempeñar las pruebas de software. Mi trabajo en Monolith y mi hobby de mantener un ejecutor de pruebas me dan, espero, una perspectiva interesante sobre esto. Entonces, para comenzar, veamos un proyecto de ingeniería entregado en los Países Bajos en la década de 1990, que costó casi medio billón de euros. Fue un éxito, 2 millones de personas dependen de él y, sin embargo, rara vez se ha utilizado. Esta es la barrera contra las marejadas musulmanas. Protege a Róterdam y sus alrededores de las marejadas. Si ampliamos un poco el mapa, comenzarás a ver todas las ciudades que lo rodean. Crecí en algún lugar al norte de eso, pero Róterdam está aquí abajo. Ahora, por supuesto, los holandeses son algo famosos por mantener el mar a raya y típicamente construimos diques, o también conocidos como diques. Es un muro para mantener el agua fuera. Y la tierra alrededor de este canal de agua está protegida por diques, pero en la década de 1980, los holandeses determinaron que los diques no eran lo suficientemente altos. Entonces, la solución obvia es hacerlos más altos, ¿verdad? Pero para hacer eso, para aumentar la altura de un dique, necesitas ensanchar la base. Y esto es difícil de hacer cuando tienes ciudades centenarias construidas junto a los diques. Código heredado, por así decirlo. Entonces, reubicar estas ciudades habría costado una fortuna y habría llevado décadas, y se requería una solución más creativa. En otros lugares del país, tenemos esto, que es el dique deslizante. Y separa el Mar del Norte de lo que ahora es un lago, pero que solía ser conocido como el Mar del Sur. Pero debido a que separa, ya sabes, un mar de un lago, es bastante fácil ensancharlo y hacerlo más alto, lo cual es un proyecto que está en marcha en este momento. Oh, y hay otro problema, que es que, en la década de 1980, el puerto de Róterdam era el puerto marítimo más grande del mundo. Creo que todavía está entre los 5 primeros o definitivamente entre los 10 primeros. No puedes cerrarlo por completo porque, bueno, ¿a dónde irán todos los contenedores? Entonces, al igual que con NPM, construimos el registro de paquetes más grande del mundo, los holandeses construyeron una de las estructuras móviles más grandes del mundo.

Entonces hay dos compuertas. Veamos si puedo reproducir esto. Aquí vamos. Hay dos compuertas que se pueden flotar en la vía fluvial y bajar, protegiendo el interior de las marejadas. Cada compuerta tiene 22 metros de altura, 210 metros de ancho, respaldada por travesaños de 237 metros de largo que descansan sobre la articulación de bola más grande del mundo, con un diámetro de diez metros, con un peso combinado de casi 15,000 toneladas. Y todo esto es controlado por una computadora porque no se puede permitir que los operadores ansiosos cierren un puerto ocupado debido a una tormenta que se avecina. Entonces, los humanos han sido reemplazados por 200,000 líneas de código C++, y el conjunto de pruebas tiene 250,000 líneas. Pero esto no es un código promedio. El sistema fue diseñado utilizando métodos formales. Puedes encontrar un documento de hace 20 años

Puedes encontrar un artículo sobre eso y solo te costará 40 euros. Ahora, no voy a recomendar eso para tu próximo componente de React, pero me da mucha confianza de que mi familia mantendrá sus pies secos. Así que, disculpen esta desviación hacia la ingeniería del mundo real, pero creo que hay algunas ideas que podemos obtener de esta barrera. Entonces, por ejemplo, en realidad no se cierra por completo, lo cual se puede apreciar aquí. Hay una pequeña brecha entre ambos brazos, porque realmente no quieres que choquen entre sí, porque quién sabe qué daño podría causar eso. Pero, ya sabes, te hace pensar en lograr una cobertura de código del 100%, ¿verdad? Ni siquiera les importa mantener todo el agua fuera. Solo tienen que mantener casi toda el agua fuera. Entonces, la programación, como profesión, y yo mismo soy culpable de esto, podemos estar terriblemente enfocados en el código, nuevas APIs, nuevos frameworks, preocupándonos por la deuda técnica. Y esto puede ser divertido y nos mantiene ocupados y nos hace parecer que estamos haciendo cosas. Entonces, en Monolith, soy un ingeniero de productos. Y en lugar de hablar más sobre ingeniería, creo que deberíamos hablar un poco sobre el producto. Entonces, construimos productos para servir a nuestros clientes. Para Monolith, eso son individuos. Para la Barrera contra las Marejadas, eso son 2 millones de individuos y negocios y una buena parte de la economía holandesa. Al igual que construir estas barreras, construir un producto es un esfuerzo multidisciplinario. Diseño, marketing, investigación, soporte, operaciones, tanto operaciones técnicas como operaciones de la empresa. Cumplimiento, ya sea GDPR o en nuestro caso, ciertas regulaciones financieras. Aseguramiento de calidad. Eso es mucho. Entonces, ¿qué contribuimos nosotros como desarrolladores de software a todo esto? Refinar infinitamente el código o descubrir cómo probar los casos límite puede ser un desafío divertido pero ¿sirve al cliente? ¿Entrega valor? Construir grandes productos requiere iteración, reflexión y hacer compromisos. Tienes que determinar tus restricciones, como no mover todo un pueblo. Tienes que hacer suposiciones, probarlas, aprender, hacer más suposiciones, y así sucesivamente. Y esto se requiere de todos, no solo de los desarrolladores. Es un acto de equilibrio en la cuerda floja. Y afortunadamente a menudo podemos permitirnos cometer errores en público. Simplemente los llamamos errores. Probar suposiciones no siempre requiere escribir código. De hecho, si asumimos que escribir código es la parte más costosa del proceso, entonces deberíamos probar tantas suposiciones como sea posible con la menor cantidad de líneas de código posible. En otras ocasiones, es más efectivo escribir un montón de código espagueti, ponerlo en producción, aprender de lo que sucede y luego cambiarlo de nuevo. Velocidad sobre calidad para poder aprender más rápidamente y entregar más valor más rápido. Y con disculpas a mis compañeros italianos por insinuar que el espagueti no tiene calidad.

Ahora, no puedo escuchar quejarte. ¿Qué pasa con la deuda técnica? Lo sé. Construir productos no es fácil. Requiere una amplia colaboración entre personas que tienen formas radicalmente diferentes de definir y resolver problemas. Siempre y cuando todos estén alineados en entregar valor al cliente, tendrás buenas posibilidades de tener éxito. Pero, por supuesto, hay cosas que podemos hacer como desarrolladores de software para ayudar en este proceso. Y sí, eso implica pruebas.

Porque el problema con escribir rápidamente software es que en algún momento, terminas. Si no con el proyecto y con ese servicio o esos componentes de UI. Y cuando terminas, sigues adelante. Y luego, tienes que volver y hacer cambios. Y no sabes si has roto algo. Así que, esa barrera contra las marejadas, la prueban cada año solo para asegurarse de que el mecanismo siga funcionando. En verano, hacen un poco de mantenimiento. Viene una nueva tormenta. Luego, a finales de septiembre, lo flotan. Ven si pueden cerrarlo. Lo cual suena lo suficientemente fácil, ¿verdad? Pero tienes que tener bastante confianza en que también flotará de vuelta. Porque no puedes bloquear el puerto marítimo durante días. Eso sería muy costoso. Y probablemente todo ese software que lo controla también recibe actualizaciones ocasionales. Así que, es bueno que tengan todo un proceso para verificar su corrección.

Siempre he pensado que el código es un reflejo de cómo entiendes un problema. Así que, cuanto más claro sea tu entendimiento, más claro será tu código, y a medida que el problema cambia, también debe cambiar el código. Y la iteración que se requiere para construir productos es lo que hace que el problema cambie. Y por lo tanto, el código cambie. Así que, las buenas pruebas también reflejan un problema, así como las restricciones que se imponen al código. Pero lo más importante, las buenas pruebas brindan confianza. Confianza en que el problema está resuelto por tu código. Confianza en que cuando el problema cambie y te encarguen cambiar el código, no romperás accidentalmente las cosas.

Escribimos pruebas para tener confianza y poder iterar sin romper nada o para entregar valor. Entonces, ¿quién realiza las pruebas en tu organización? Los equipos de control de calidad dedicados. Pueden ser fantásticos. Pero debemos evitar una cultura en la que deleguemos la responsabilidad. Los equipos de desarrollo de software deben tener confianza en su código y se les debe exigir que escriban sus propias pruebas. Por supuesto, dado que estás asistiendo a esta conferencia, probablemente no seas del tipo que compara benchmarks. Ahora, si puedo hacer una confesión, no me gusta escribir pruebas. No creo que alguna vez lo encuentre divertido. Pasar días escribiendo pruebas para un nuevo servicio, incluso cuando se trata de un sistema de autenticación críticamente importante. Escribir pruebas puede ser tedioso, sentir que te ralentiza y te impide iterar menos y entregar menos valor.

Entonces, mi consejo es enfocarse en la confianza, no en las metodologías, ya sea que sigas el enfoque de desarrollo guiado por pruebas o el enfoque de desarrollo guiado por comportamiento, no en las bibliotecas de aserciones y APIs. Porque realmente, ¿cuántas abstracciones puedes manejar? ¿Cuántos frameworks puedes aprender? Utilízalos en tu código real. Utiliza esa energía para tu código real y evita abstracciones innecesarias en tus pruebas. No sigas metodologías solo porque son mejores prácticas. En cambio, haz lo que tenga sentido para ti y tu equipo. ¿Estás construyendo mejores productos o estás perdiendo tiempo? Entonces, el código que tiendo a escribir se ejecuta en el backend. Por lo tanto, dentro de ese contexto, he descubierto que las pruebas de integración son buenas si reflejan un problema que estás resolviendo. Si no puedes usar una prueba de integración pero quieres probar un área crítica del código, entonces utiliza una prueba unitaria. Las restricciones, a menudo se presentan en la validación de las entradas y ahí es donde realmente quieres probar casos extremos. Pero lo más importante, escribe código. Escribe código que pruebe, ten confianza y construye productos increíbles. Gracias. Y espero poder charlar contigo en una sesión de preguntas y respuestas. Hola, Mark. Hola. Muchas gracias por unirte a nosotros. Sí. Y mágicamente en una habitación diferente.

Sí. Mágicamente en una habitación diferente. Sí, de todas partes. Entonces ¿cuál es tu principal responsabilidad laboral? Quiero decir, diría que construir un mejor producto. Eso es más o menos de lo que puedo hablar. Sí. Supongo que antes de cambiar de posición, cuando era más desarrollador de software, esa también era mi principal responsabilidad. Pero ahora no estoy seguro de qué responder a esa pregunta, en realidad. Tendré que pensarlo. Al igual que tengo que pensar en la iteración, la reflexión y hacer compromisos. Es una cita realmente genial. Me gusta.

Y Yuval Dagnar preguntó cuándo el código espagueti es un costo demasiado alto para la confianza. ¿Tienes alguna opinión al respecto? Bueno, ¿es esa la pregunta correcta, supongo? Es un compromiso entre los compromisos que estás haciendo con el código. Y cuanto más compromisos hagas con los clientes, más necesitas tener confianza. Entonces, si el código está moviendo dinero y no estás seguro de que vaya al lugar correcto, eso será un gran problema. Si el código envía notificaciones push, pero la mitad del tiempo no lo hace, tal vez eso no sea un gran problema. Sí, el caso de uso siempre juega un papel importante en cuáles deberían ser tus prioridades. Pero tradicionalmente, si recuerdo cuando estaba en la universidad y todo eso, todos me decían que el código espagueti es malo. No lo hagas. Pero bueno, eso es lo que te dicen cuando estás aprendiendo cosas, porque siempre es demasiado tentador seguir adelante. Y nunca mejorarlo, lo cual también cuando estás aprendiendo cosas, tienes que intentar escribir mejores sistemas desde el principio. De lo contrario, es posible que nunca aprendas a hacerlo. ¿Verdad? Siempre estás escribiendo código espagueti. Sí. Pero creo que cuando estás construyendo algo, a menudo el problema no es qué tan bueno es tu código. El problema es, bueno, ¿qué es lo que realmente necesitan los usuarios de esto? Y eso es lo que realmente tienes que aprender. Porque no importa si tienes un código muy bueno, pero tu producto no resuena. Sí. Si el producto... Porque no resuelve el problema para el usuario, es... Sí. Sí.

Sí. Supongo que tienes que aprender cómo construir adecuadamente las cosas para poder ver cuándo está bien construir cosas que no son muy buenas o donde se permite escribir código que no cumple con todos los... ¿Cuál es la palabra? Que no cumple con los estándares de calidad. Y Jubil Datma escribió una pregunta de seguimiento. Si tengo confianza en mis pruebas, pero no se construyen de manera consistente, ¿no reduce la confianza? ¿Si las pruebas no son consistentes? Si tengo confianza en mis pruebas, pero no se construyen de manera consistente, ¿no reduce la confianza? Recuerdo situaciones en las que teníamos pruebas que eran inestables, o en algunas situaciones de proyectos las pruebas no se ejecutaban regularmente. Tal vez eso es a lo que se refiere. O tal vez las pruebas mismas no siempre se ejecutan. Sí. Quiero decir, tal vez hay dos lados. Si estás cambiando código, o si algo cambia, entonces necesitas asegurarte de que estás ejecutando tus pruebas. Si desactivas accidentalmente tus pruebas, entonces, bueno, no están probadas. Porque aunque las pruebas y el código existan, nunca se ejecutan. Pero a veces todo lo demás cambia. Tu código no cambia, pero la plataforma en la que se ejecuta cambia. La versión de Node cambia. Digamos, en los viejos tiempos antes de Docker, instalabas Node en una máquina, y ahí es donde ejecutabas tu código. Entonces, si actualizas esa versión de Node, no has cambiado la implementación del código. Así que entonces tienes que asegurarte de haber probado con esa versión más nueva de Node. E incluso ahora, si usas imágenes de Docker, es posible que no ejecutes tus pruebas contra la salida de compilación final, así que aún quieres asegurarte de que todas esas cosas sean iguales. Esperemos que eso nos dé una respuesta. Esperemos, y si no, él puede unirse a la sala de oradores más tarde y tal vez hablar contigo al respecto

directamente. Y Nikolaj Advolodkin, lamento mucho por mi pronunciación de los nombres, preguntó, me gustaría entender cómo equilibras cuántas pruebas escribir para tener esa confianza? Nuevamente, es difícil responder eso como una regla, porque depende de dónde no tienes confianza. Entonces, algunas cosas, si usas TypeScript, y estás, estás llamando a una API y está verificada por tipos, puedes tener bastante confianza en que sabes que esos argumentos están bien, los estás usando de la manera correcta. Entonces, es posible que no tengas que probar todo eso. Pero en otros casos. Sí, supongo que depende. Como en el caso de mi proyecto personal, rara vez tengo una cobertura de pruebas alta. Pero cuando estoy trabajando en sistemas que manejan información sensible o algo así, definitivamente quiero tener muchas pruebas. Y de lo contrario, personalmente no me siento confiado en el código. Así que depende. Sí. Tal vez la respuesta nuevamente, esa es otra pregunta, ¿cuál es lo peor que podría pasar? Si el código no funciona como se anuncia. Entonces, nuevamente, si se trata de dinero, bueno, tomar dinero de la persona equivocada o vender dinero demasiado pronto, realmente quieres probar eso. En el Reino Unido, hace un par de semanas, borraron accidentalmente un montón de registros criminales. Demasiado pronto, funcionaron. Sí. Los registros caducan después de cierto tiempo, porque el sospechoso no fue condenado, y así sucesivamente. Entonces, hay código que borra esos registros, pero borró demasiados registros. Estoy seguro de que es un sistema realmente difícil de gestionar y difícil de probar, pero sí, es un área donde realmente quieres asegurarte de que no estás borrando lo incorrecto. Sí, me gusta la pregunta, como, ¿cuál es lo peor que puede pasar, tal vez usarlo como una medida de mi confianza en las pruebas? La otra cosa a tener en cuenta es que tu tiempo tiene un costo, voy a asumir que trabajas en un negocio o eres un empleado o un contratista, tu tiempo tiene un costo y si eres un empleado, no tienes que preocuparte demasiado por desperdiciar el dinero de tu jefe. No en extremo. Pero a veces lo peor que puede pasar no es muy costoso y no es muy probable. Entonces, gastar mucho tiempo en prevenir eso puede que no valga la pena. Pero tampoco es fácil tomar esa decisión. A veces puede no costar mucho dinero, pero puede llevar mucho tiempo limpiarlo. Entonces, aún así cuesta dinero. Sí, debes considerar el costo de construir las pruebas y ejecutar las pruebas regularmente, pero también debes considerar el costo de no probar tu código, ¿verdad? Así que tenemos algunas preguntas más. Jacek preguntó, ¿qué tal comenzar con Código Espagueti y un conjunto de pruebas de extremo a extremo para mantenerse en el camino? Sí. Quiero decir, no estoy diciendo que no escribas pruebas hasta que estés listo para escribir buen código. De acuerdo, Asa... Haz lo que te haga sentir cómodo.

Oh, disculpa. Sí. No, no, no. Por favor, amplía si quieres. Si no, también puedes unirte a la sala de oradores más tarde y hablar más sobre esto. Entonces, Asa100 preguntó, ¿cómo puede un equipo de pruebas ayudar a fomentar una cultura de desarrolladores que desaliente lanzar características sin tener en cuenta? No he tenido el privilegio de trabajar con un equipo de pruebas, por lo que es difícil responder eso desde la experiencia. Creo que se trata más de ayudar a otras personas en la organización a preocuparse por las pruebas y facilitarles la escritura de pruebas y cambiar la cultura para que no sea para que las personas sientan que las pruebas son parte de su responsabilidad y sientan que tienen apoyo para hacerlo. Sí. Sí, supongo que si a las demás personas les importa, entonces no habrá lanzamiento sin tener en cuenta. Tenemos tiempo para una última pregunta. Testybite quiere saber, ¿cuál es tu definición de pruebas de integración? Si no estás simulando todo en tus pruebas unitarias, ¿es eso una prueba de integración? No estoy seguro, no soy muy estricto con esas definiciones. Lo que hago en las pruebas de servicio es, inicio una base de datos, aparece. Simulo los servicios de terceros. El código que estoy probando, todo eso se está ejecutando. Y está utilizando una base de datos y almacenando cosas. Y puedo observar esos efectos. Puedo controlar los datos que ingresan ya sea desde una solicitud que hago en mi prueba o desde el servicio simulado con el que se comunica. Entonces, no es una prueba de integración de extremo a extremo porque no estoy utilizando un servicio en vivo. Pero creo que es lo suficientemente bueno para tener confianza en el servicio que estoy probando. Pero debes asegurarte de que todas las simulaciones sean correctas. Si lo modelas de manera diferente a lo que sucede en producción, seguirá siendo incorrecto. Muchas gracias por unirte a nosotros. Que tengas un buen día, Marc, y puedes unirte a él en la sala de oradores. Sí, gracias por recibirme, y que todos disfruten de la conferencia.