Mockear o no mockear - Esa es la pregunta

♪ Hola, bienvenidos a esta charla. En ella, intentaremos responder una pregunta, que es, ¿hacer una simulación o no? Comencemos.

Mi nombre es Rita. Soy una apasionada de la tecnología. Vivo en Lisboa con mi hermosa familia. Mi hijo tiene casi tres años, así que es un poco travieso. Pero cuando no estoy ocupada con mi familia, probablemente estaré jugando, o estaré en SDC, el lugar donde trabajo. Trabajo con estas personas increíbles. Y actualmente, soy parte del Equipo Falcon, y las cosas están volviendo lentamente a la normalidad aquí en la oficina.

¿Dónde está la oficina? Es un centro de desarrollo de software aquí en Lisboa, y está justo en el centro de la ciudad. Se estableció en 2018. Fue el primer centro de desarrollo de software que Volkswagen abrió fuera de Alemania. Y hasta ahora, las cosas han ido muy, muy bien.

¿Qué hacemos aquí? Entonces, desarrollamos productos utilizando programación extrema. En pocas palabras, es un marco ágil que nos permite producir y entregar software de alta calidad a un ritmo muy rápido con una buena calidad de vida para nosotros, los desarrolladores, o para todo el equipo de desarrollo. Fue creado por Kent Beck en 1996. Así que es algo antiguo, pero los valores fundamentales en los que se basa, aún se mantienen. Comunicación, simplicidad, retroalimentación, valentía y respeto. Estos cinco pilares, también están grabados en el espíritu de SDC. Así que es una combinación perfecta.

¿Qué más puedo contarles sobre SDC? Entonces, trabajamos en equipos equilibrados, lo que significa que un equipo está compuesto por diseñadores, gerentes de producto y nosotros, los desarrolladores. Un equipo, permítanme también enfatizar esto, un equipo de producto, porque el equipo es más grande que solo los equipos de producto. Los diseñadores, ¿qué hacen? Entonces, mantienen contacto con los usuarios. Exploran, investigan, investigan posibles soluciones para los problemas de los usuarios. Los gerentes de producto traducirán estas necesidades de los usuarios en historias, y también mantendrán contacto con el negocio y verán si un producto es o no viable para ser desarrollado desde el punto de vista del negocio. Y nosotros, los desarrolladores, nos encargaremos de la viabilidad en términos de tecnología. Seremos los responsables de ver si algo se puede integrar con sistemas heredados, si algo se puede hacer utilizando tecnología de vanguardia. Si se trata de tecnología, ese es nuestro ámbito. En el medio de estos tres roles muy diferentes, es donde realmente sucede la magia y donde nacen buenos productos.

Entonces, ¿qué hacemos y cómo lo hacemos? Entonces, nosotros los desarrolladores, hacemos desarrollo impulsado por pruebas.

Lo que significa que primero escribimos algunas pruebas, ejecutamos las pruebas, esperamos ver que las pruebas fallen. Pero si las pruebas pasan, las pruebas pasan. No, no deberían pasar. Tal vez hubo un error en la prueba, lo más probable. Entonces, para minimizar este tipo de situaciones, también participamos en la programación en pareja. Lo que significa que siempre tienes dos pares de ojos mirando el mismo código. Tenemos una computadora, dos teclados, dos ratones, dos pantallas, y así es como desarrollamos. No es necesario hacer revisiones de código porque el código se revisa en vivo a medida que avanzas. No te quedas bloqueado porque si te quedas bloqueado siempre habrá alguien contigo. Podrás expresar tus pensamientos, participar en una conversación de manera rápida y eficiente, podrás desbloquear el hilo de pensamiento que tienes. Así que funciona muy bien, tengo que admitirlo. Y no podría hacerlo de ninguna otra manera.

Entonces, yendo al núcleo de la presentación. Voy a hablarles un poco sobre los libros. Libros, ¿por qué? Bueno, los libros pueden llevarte a cualquier lugar. Pueden llevarte a lugares y contarte historias que nunca podrás ver en la vida real. Así que, también tenemos un poco de biblioteca aquí en el SDC. En realidad, son dos estanterías con libros, pero es una biblioteca. Así que podemos sacar libros de ella. Por lo tanto, tiene un sistema de gestión. ¿De qué está compuesto? Es un bloc de notas. Es un bloc de notas en el que escribimos nuestro nombre, el libro que tomamos y cuando lo devolvemos, lo tachamos. Así que, sí, un poco. Así que llevemos esto al siglo XXI, ¿de acuerdo? ¿Qué tal si cavamos en nuestras propias metodologías? En lugar de tener el bloc de notas, intentemos obtener una solución tecnológica para el bibliotecario. Así que hablemos con las personas que solicitan y desarrollan los libros y entregan los libros a las personas encargadas de mantener la biblioteca. Y hagamos un par de bocetos. Así es como visualmente intentaríamos lograr y cumplir. Fue un punto de partida.

Entonces, obtengamos un MVP, un MVP adecuado.

Y de la investigación que hicimos, las cosas valiosas y las cosas que planteaban los problemas más relevantes para los usuarios eran poder agregar libros a la biblioteca, poder tomar prestados libros de la biblioteca y devolver libros de forma natural. Así que podemos agregar libros. Habrá una página para ellos. Sin embargo, dado que las personas tienden a ser un poco impacientes en el teclado, también tengamos alguna validación para asegurarnos de que todo esté correcto antes de enviarlo. Tengamos una página separada en la que podamos ver qué libros están disponibles en la biblioteca. Tengamos la posibilidad de tomar prestado un libro. Veamos qué libros hay en el mundo. Y tengamos la posibilidad de devolverlos a la biblioteca.

Estos son los bocetos que tenemos. Entonces, ¿qué sigue? ¿Cómo pasamos de estos bocetos a los componentes de React que desarrollaremos? Obviamente, desarrollaremos esto utilizando React. Entonces, ¿cómo pasamos de los bocetos a React y a nuestros componentes de React? Bueno, aquí entra en juego el diseño atómico. El diseño atómico es una forma de organizar tus componentes y tus elementos visuales como un sistema de diseño, muy probablemente. Y está estructurado de una manera muy sencilla y creciente o aumentando en complejidad. Tienes átomos, tienes moléculas, donde los átomos son los más simples, las moléculas son grupos de átomos unidos, los organismos son grupos de moléculas y átomos unidos, las plantillas serán el lienzo donde dices, ok, quiero tener esto aquí, esto allá, esto justo aquí abajo, y luego las páginas cuando instancias las plantillas. Así es como Brad Frost definió el diseño atómico en 2013. Sin embargo, hicimos algunos ajustes para nuestro propio uso. Así que nos quedamos con los átomos, sí, bien. A partir de nuestros diseños, los átomos también serán botones, algo muy simple. Las moléculas son grupos de átomos unidos o más de una etiqueta HTML juntas. Los organismos, como una tarjeta de libro o una plantilla para las páginas de las estanterías de libros, obtienes una plantilla y cuando instancias esa plantilla, cuando instancias la plantilla, terminas con las páginas de las estanterías de libros. Sin embargo, este es el momento en el que rompimos con la metodología original porque dijimos, ok, pero los organismos también pueden tener plantillas, lo cual es bastante genial, y como tal, tenemos nuestra desviación.

Ok, así que empecemos y comencemos a codificar. ¿Dónde? Podrás tener el repositorio que he utilizado para esta presentación disponible aquí, y comienza con algo muy simple, un lienzo en blanco con un encabezado, un contenido principal y luego el pie de página. ¿Qué queremos lograr con esto? Ok, estaremos haciendo desarrollo impulsado por pruebas. Desarrollaremos la página para agregar un nuevo libro y seguiremos el flujo del usuario para agregar un nuevo libro a la biblioteca. Todo bien. Empecemos.

El desarrollo impulsado por pruebas, lo que significa que tendremos que escribir pruebas. Para escribir pruebas y tener al usuario en el centro de todo, hemos elegido usar la biblioteca de pruebas de React porque, como dijo Kenti Dodds de una manera muy elegante, cuanto más se parezcan tus pruebas a la forma en que se utiliza tu software, más confianza te brindarán. Y esto es algo con lo que nos identificamos y creemos que es una buena manera de seguir el desarrollo impulsado por pruebas.

Entonces, usaremos la biblioteca de pruebas de React para esto. Comencemos con la página de nuevo libro. ¿Qué tenemos aquí? Bueno, tenemos el formulario que contendrá el botón de guardar deshabilitado. Renderizaremos solo los componentes, o en este caso, la página, para tener lo mejor. Será el componente. El componente para tener el formulario para escribir un nuevo libro con todos los elementos, el encabezado, las diferentes secciones de entrada, los botones y, idealmente, tener el botón deshabilitado. Prueba sencilla.

Por supuesto, falla porque no hay nada, no hay nada. El componente está limpio. No hemos hecho ningún código de producción. Así que pongámonos manos a la obra. Cuando agregas algo de código de producción, vuelves a ejecutar las pruebas y tus pruebas siguen fallando. ¿Por qué fallan? Porque fuimos un poco permisivos con la prueba y la persona que implementó el código se retrasó un poco con la escritura. En lugar de tener 'author' correctamente escrito, fuimos algo creativos. ¿Por qué? Porque la prueba usaba regex, lo que nos permitió ser un poco flexibles con la definición de la cadena. Si lo corriges para la ortografía correcta, tu prueba pasa. Genial, ¿no? Pero somos desarrolladores front-end, así que siempre nos gusta ver cómo quedan las cosas.

Y así es como se ven las cosas, ¿no es genial? Entonces intentemos arreglarlo. ¿Cómo podemos arreglarlo? Podemos escribir otra prueba. Y en lugar de usar la biblioteca de pruebas de React tal como está destinada a usarse, ajustémosla un poco. ¿Recuerdas la molécula de entrada? Digamos que queremos llamarla. Simulémosla y digamos que queremos llamarla con los parámetros que esperamos ver. Hagamos lo mismo para los botones OK y Cancelar como molécula y sigamos adelante. Sí, lo sabemos. Obviamente no se llama. Así que llamémoslo.

Cuando implementas el código, tu prueba pasa. Fácil. Misión cumplida. Y como bonificación, cuando ves cómo se ve, ta-da. Sí, esto es lo que queremos. Estamos avanzando.

Además, cuando hacemos clic en el botón Cancelar, la investigación mostró que nos gustaría volver a la página de inicio. Para eso, usemos React Router DOM para poder navegar entre nuestras páginas. Así que esperemos que se haya llamado a history push. Realmente no se ha llamado, así que sí, sabemos que no se ha llamado, así que llamémoslo. Cuando lo llamamos, ambos sabemos que cuando lo llamamos en el callback para Uncancel, nuestra prueba se vuelve verde y todo está bien. Súper fácil. Muy fácil.

Te he mostrado dos formas diferentes de hacer esto para este componente simple, este formulario simple. Pros y contras. Cuando haces mock de los componentes, es fácil pasar de los diseños a los componentes que estás usando, lo cual es genial. No puedes hacer trampa con los componentes que usas, porque si quieres usar nuestro botón, usarás nuestro botón, no usarás la etiqueta HTML para el botón. Cuando renderizas tu componente, lo haces en un entorno controlado, por lo que puedes simular la navegación hacia atrás y hacia adelante o hacia donde quieras ir sin muchos problemas. Sin embargo, la desventaja es que tienes algunas representaciones superficiales, lo cual sé que va en contra de lo que representa la biblioteca de pruebas de React, pero nuevamente, pros y contras. Eventualmente, es posible que termines con algunas pruebas duplicadas aquí y allá. Lo cual está bien, y tienes un acoplamiento estrecho con los detalles de implementación. Dijimos que queremos usar React Router DOM. Eso es lo que vamos a usar para la navegación. Pros y contras. No hay una respuesta correcta o incorrecta aquí.

Continuando. Cuando tienes formularios, si esto es nuevo para ti, mi consejo es que uses Formic en combinación con YUP para su validación. Está mejor probado, es increíble, debo decirlo, y es bastante fácil de familiarizarse con. Así que pongámonos manos a la obra con Formic y YUP.

En las pruebas, ¿cómo te aseguras de que estás usando Formic? Lo simulamos y esperamos que se haya llamado. Fácil. No se llama, sí, obviamente no se llama. Por supuesto que no, porque acabamos de introducirlo. Lo llamamos así, y la prueba pasa. Pero si solo fuera tan simple. Tal vez deberíamos leer un poco más sobre Formic. Entonces, en Formic obtienes el ejemplo básico, y a partir de ahí puedes ver fácilmente que necesitamos proporcionar más información a Formic, como los valores iniciales y lo que queremos hacer cuando enviemos el formulario, y hablando de enviar, eso es lo que queremos hacer. Pero el botón está desactivado. Queremos hacer clic en él. ¿Cómo lo hacemos, cómo habilitamos los botones? Bueno, investigando más, descubrimos que existe esta propiedad válida que va junto con dirty, y luego tendremos que ver cómo podemos usarla en los forms, pero espera. ¿Qué queremos hacer? ¿Queremos pasar tiempo aprendiendo a simular esta biblioteca de terceros? ¿O queremos pasar tiempo usándola? La respuesta es bastante simple, lo que significa que hablemos de ello. Necesitamos decidir qué queremos hacer. Y como equipo, hemos decidido que queremos usar Formic tal cual, sin simularlo. Vamos a por ello de manera justa y directa, y así lo hacemos. Entonces, en lugar de tener todos los forms, nos enfocamos en la parte en la que vamos a enviar. Entonces, cuando vayamos a enviar, tendremos un servicio para agregar el libro, y esperaremos que se haya llamado, pero obviamente no se llama. Entonces, si vamos al formulario que ya está completado con más cosas de Formic, llamamos a add book. Y tenemos una prueba verde que pasa. Así de fácil. No hay problema. Pero, ¿qué es esto? ¿Qué es este servicio? Este servicio está documentado a través de las pruebas. Así que es otra ventaja del desarrollo guiado por pruebas. Las pruebas son tu documentación. Serán tu referencia para las cosas y la información que necesitas extraer. Entonces, el servicio para agregar un libro es simplemente un servicio que llama al endpoint slash-API slash books con los datos proporcionados. Solo eso, no mucho. Ahí lo tienes. Llama al fetch que proviene de un servicio de fetch que a su vez es algo que tenemos en BookKeeper que encapsula la API de fetch. Así que hay un par de capas aquí.

Pero Trek nos dijo que las capas son buenas. Las capas son geniales. ¿Por qué tenemos capas? Procon. Cuando tienes capas en este caso, obtienes mucha abstracción aquí. Por lo tanto, puedes ignorar si estás utilizando la API de fetch, axios, node fetch, una biblioteca que hayas creado tú mismo. Realmente no nos importa. Está oculto, escondido debajo del servicio de fetch que se utiliza en toda la aplicación. Y estás bien con eso. Y también estás bien simulándolo. Entonces, en lugar de intentar simular todos los lugares donde utilizas la biblioteca, simplemente puedes simular la llamada al servicio. Esto facilita mucho las pruebas. Sin embargo, terminarás investigando que necesitarás hacer si quieres entender cuáles son los servicios y dónde se encuentran.

Para resumir, ahora podemos centrarnos en todo el recorrido de Bob. Bob quiere usar BookKeeper. Quiere usar BookKeeper, que es el nombre de nuestra aplicación, si no te has dado cuenta. Renderiza toda la aplicación, todo. Sin simulación alguna, excepto Global Fetch, que es la parte más importante de tu aplicación, cuando simulas esta parte más importante. Puedes enfocarte mucho, mucho en el recorrido del usuario. Recórrelo con fluidez a través de las bibliotecas de pruebas de React, y por supuesto, la prueba fallará debido al desarrollo basado en pruebas. Recuerda, comenzamos con un lienzo en blanco en BookKeeper. Así que agreguemos cosas. Agreguemos la navegación con React RouterDOM, cambiando entre la página de inicio, la página para agregar nuevos libros, y eventualmente la página para tomar prestados libros. Las cosas pasarían. Pros y contras en este enfoque. Probablemente puedas decir que, sí, eso se parece mucho a una prueba de extremo a extremo, y podríamos hacer esto usando Cypress en lugar de la biblioteca de pruebas de React en el desarrollo front-end. Sí, podrías. Pero si lo haces así, en realidad puedes enfocarte en el recorrido del usuario, algo que también podrías hacer en la prueba de extremo a extremo. Justo. Pero en este caso, no tienes que preocuparte por tener un backend en funcionamiento. Solo necesitas tener en cuenta cuáles son los puntos finales, y cuál es la interfaz que tu backend te proporciona. Luego simplemente puedes simular las respuestas que deseas tener. También puedes centrarte en la accesibilidad. Puedes probar toda tu aplicación a través de los ojos del usuario, cómo percibe tu aplicación, y eso es algo realmente valioso. Los contras de esta parte... Realmente no encontré ninguno, así que, lo siento. Para resumir, comenzamos haciendo la pregunta, ¿debemos simular o no? Me gustaría poder decirte que tengo una respuesta, pero la realidad honesta es que no lo sé. Hay casos en los que es mejor simular, hay casos en los que es mejor usar el verdadero. Depende de ti encontrar tu equilibrio, ver qué funciona mejor para ti y para tu equipo, y luego hacer lo que te parezca correcto. No hay una respuesta correcta o incorrecta, solo encuentra tus equilibrios, seguro. Hay casos en los que es más beneficioso simular, hay casos en los que es más beneficioso no simular, pero eso surge de la experiencia, y es algo que solo tú puedes descubrir. Así que eso sería todo. Muchas gracias por escuchar. Si tienes preguntas, adelante. ¡Adiós!