Desglosando la complejidad en las pruebas

Hola a todos. Mi nombre es Artem y soy ingeniero de software en Kotlinbox. Hoy me gustaría hablar sobre la complejidad en las pruebas, pero antes de comenzar, permítanme hacerles una pregunta simple. ¿Alguna vez han sentido que escribir una prueba para una funcionalidad requeriría más tiempo y esfuerzo que la propia funcionalidad? Bueno, al igual que yo, ustedes también lo han sentido. Entonces, es probable que estuvieran lidiando con una o tal vez varias formas en las que la complejidad puede manifestarse en su base de código.

Pero no deberían sentirse mal al respecto, porque no importa qué tan buenos ingenieros seamos y qué código increíble escribamos, la complejidad está destinada a ocurrir. Está bien. La complejidad en sí misma no es el problema. Lo que importa es cómo elegimos lidiar o no lidiar con cómo se manifiesta. Y aunque la complejidad puede ser un tema amplio, para el propósito de la charla de hoy, me gustaría referirme a ella como una cualidad o estado de ser difícil de escribir, entender y mantener una prueba. Y cuando se trata de la complejidad en las pruebas, se puede dividir en dos grupos principales. Es la complejidad que proviene del sistema que estamos probando, y esto puede ser cualquier código. Un componente de React, un controlador de ruta en el backend o una biblioteca de JavaScript. Y la complejidad que proviene de las pruebas que estamos escribiendo.

Así que comencemos desde el sistema. Y una de las formas más comunes en las que las personas se encuentran con la complejidad, proveniente del código que prueban, es que no saben qué probar. Estoy bastante seguro de que han estado en esta situación. Abren un archivo existente y parece que está haciendo todo lo posible en el universo, y no tienen ni idea de cómo abordar eso en las pruebas. Bueno, en realidad hay una gran regla que pueden seguir en estas situaciones. Es, cuando tengan dudas, comiencen probando las rutas más críticas para el usuario. Entonces, si están construyendo un producto de comercio electrónico, comenzar una estrategia de pruebas desde un flujo de registro o un flujo de pago tiene mucho sentido. Y si están desarrollando herramientas internas o bibliotecas, entonces comiencen desde esos flujos felices que los usuarios esperan, y eso los pondrá en el camino correcto.

Y luego, cuando sepan qué probar, el siguiente problema más grande, el próximo desafío, es cómo probar eso. Y creo que muy a menudo, cuando nos sentimos luchando con cómo abordar las pruebas, es porque podemos estar pasando por alto algún tipo de filosofía de pruebas. Y uno de los enfoques más útiles que he adoptado a lo largo de los años es probar como el usuario. Lo que significa es que cuando escriban una prueba, traten de modelarla desde la perspectiva del usuario. Entonces, las acciones de prueba que realicen emularán las acciones que ese usuario haría con su software. Y las afirmaciones que escriban realmente reflejarán las expectativas del usuario como resultado de sus acciones. Y luego, otra cosa que ayuda enormemente es cuando invierten lo suficiente en la configuración de las pruebas. Y siento que esto se pasa por alto con demasiada frecuencia y es una lástima, porque la configuración de las pruebas es quizás una de las fases más importantes que trata con la complejidad.

Debido a que el objetivo de esta fase es crear este universo, esta caja, donde cualquier prueba puede ejecutarse, o cualquier prueba que desee escribir puede ejecutarse sin problemas. Y hablaré sobre la configuración de las pruebas un poco más adelante en la charla.

Bien, cuando sabes qué probar y cómo probar, es posible que te encuentres con otro problema que es escribir demasiadas pruebas. Y puede sonar como algo bueno al principio, pero en realidad no lo es porque cada prueba debe tener un propósito. Y a menudo parecemos olvidar el propósito detrás de las pruebas en general.

Y escribimos pruebas no para obtener cobertura de código o para que CI pase, aunque queremos eso. En realidad, escribimos pruebas por una sola razón. Y es que escribimos pruebas para describir la intención detrás del sistema. Piénsalo. Cada vez que escribes una pieza de lógica en tu código, tienes alguna intención. Quieres que ese código haga algo. Pero a menos que tengas una prueba automatizada para validar esa intención, no tienes ninguna prueba de que tu código funcione como se espera.

Entonces, la próxima vez que te enfrentes a una prueba, hazte una pregunta. ¿Lo que estoy testing está realmente relacionado con la intención detrás de este código? Porque si no lo está, es probable que puedas eliminar esta prueba y aún no perder valor en tu configuración de pruebas.

Y luego, la otra cosa es que, bueno, el mundo real es mucho más complejo que eso. Y a veces hay sistemas objetivamente complejos, ¿verdad? ¿O no? Porque una cosa que me encanta de las pruebas es que la testabilidad del sistema es una prueba implícita en sí misma.

Ahora, lo que esto significa es que cuando tienes sistemas mal diseñados, mal arquitecturados, como consecuencia, serán realmente difíciles de probar. Y lo contrario también es cierto. Permíteme darte algunos ejemplos de cómo se manifiesta esto.

Entonces, en esta función obtener usuario, obtenemos el usuario de la database. Pero también obtenemos todas las publicaciones del usuario. Y esto parece que no pertenece aquí. Porque ahora, para probar correctamente esta función, también necesitamos simular todo lo relacionado con las publicaciones. Y esto es un desafío. Lo que tal vez sería el enfoque adecuado aquí sería dividir esta función en dos y probarlas por separado, lo que sería mucho más fácil.

Otro ejemplo está relacionado con las dependencias que nuestro código introduce. Como este controlador de carrito de compras. Puedes ver que en el constructor, creamos una nueva conexión de database. Tal vez eso no sea una buena idea porque para probar este controlador ahora, necesitamos simular implícitamente este constructor de database de alguna manera. ¿Por qué no simplemente pasarlo como argumento al constructor, hacer inyección de dependencias y así permitirnos probar, por ejemplo, contra la database de prueba durante las pruebas, lo que haría toda esta experiencia mucho más fácil.

Pero mi objetivo aquí no es darte algunos consejos prácticos sobre cómo escribir un código mejor. Estoy bastante seguro de que ya lo sabes. Solo estoy tratando de animarte a seguir esas mejores prácticas. Porque cuanto mejor código escribas, mejores serán las pruebas para ese código. Así que las mejores prácticas importan.

Entonces, para resumir. ¿Cómo abordamos la complejidad que proviene del sistema? En primer lugar, establecemos una estrategia clara de pruebas. Y cuando tengamos dudas, probamos los caminos más críticos que enfrenta el usuario. Luego adoptamos alguna filosofía, por ejemplo, como probar como el usuario, lo cual realmente nos ayuda a modelar nuestras pruebas de manera más fácil y sabemos cómo abordar cualquier lógica que probemos. Necesitamos invertir en la configuración de pruebas porque es una de las partes más importantes de la configuración que nos permite escribir cualquier prueba que necesitemos. Y, por supuesto, podemos utilizar la testabilidad como una especie de verificación implícita para ayudarnos a ver que el código que estamos escribiendo sigue siendo fiel a la intención que tenemos para ese código.

Bien, ahora hablemos de la complejidad en las pruebas. Y una cosa que a menudo viene a la mente es que nosotros mismos introducimos esa complejidad. Por ejemplo, al elegir el entorno de pruebas incorrecto. Imagina que estás probando una página de Next.js, pero decides hacerlo en GSDOM. Bueno, vas a tener un mal momento porque ese entorno no está diseñado para probar páginas completas. Lo mismo ocurre si decides probar una función simple de JavaScript y generas una instancia completa de Chromium para hacerlo. Seguro, eso funcionaría, pero ¿es realmente el enfoque correcto? Y para resolver esto es muy sencillo. Elige el entorno de pruebas adecuado, y a menudo es el entorno en el que se destina a ejecutar tu código. Entonces, si es una página de Next.js, simplemente lánzala en un navegador y automatiza las pruebas allí. Si es una función simple de JavaScript, tal vez un marco de pruebas basado en Node.js sería suficiente para probarla de manera eficiente.

De acuerdo, ahora, lo otro, y tal vez una de las cosas más cruciales en toda la sección de pruebas, es la configuración de pruebas. Y con qué frecuencia nos falta. Lo mencioné brevemente antes, así que profundicemos más aquí. La idea detrás de la configuración de pruebas es crear un entorno donde cualquier prueba que necesites pueda ejecutarse. Por eso esta fase debería hacer la mayor parte del trabajo pesado en términos de mitigación de la complejidad.

Entonces, aquí es donde se realiza la simulación de solicitudes HTTP, donde se crean bases de datos de prueba o se simula la conexión a bases de datos y se abordan cualquier tipo de efecto secundario que tu código comúnmente introduce. Por eso es crucial utilizar también las fases de configuración y acción. Permíteme mostrarte cómo hacerlo con un ejemplo. Cuando se trata de mitigar la complejidad, realmente quieres hacer la mayor parte en la fase de configuración, como mencioné. Una de las razones es porque lo haces una vez y tienes este entorno donde puedes ejecutar cualquier prueba, lo cual es genial. Pero incluso después de eso, seguirás teniendo cierta complejidad ocasional proveniente de las acciones de prueba que realizas, porque a menudo hay cierta lógica, ciertas abstracciones que hacemos en las pruebas, y simplemente puedes moverlas a funciones auxiliares y utilidades y reducir el desorden visual, pero también la complejidad de las pruebas en general. Y definitivamente nunca quieres abordar la complejidad en el nivel de las afirmaciones. Y te mostraré un ejemplo de por qué en un momento.

Pero lo más importante, mantenlo simple. Una vez tuve el placer de revisar una solicitud de extracción que tenía como objetivo mejorar la configuración de pruebas. Y aunque era genial, me avergüenza admitir que me llevó alrededor de 25-30 minutos entender qué hacía la configuración de pruebas para una sola prueba. Media hora, pero ni siquiera estaba cerca de entender qué hace la prueba, qué hace el código detrás de la prueba. No, solo la configuración. Y es realmente importante tener esto en cuenta al abordar la complejidad. Realmente no deberías responder a la complejidad con más complejidad porque las matemáticas siguen siendo válidas y uno más uno puede ser igual a dos complejidades. En cambio, quieres responder a la complejidad con granularidad. Entonces, funciones pequeñas con un propósito único que en total contribuyen a crear la configuración de pruebas que necesitas.

De acuerdo, ahora hablemos de las afirmaciones. Creo que, en aras de reducir la complejidad y la repetitividad, a veces tendemos a exagerar. Y aquí tienes un ejemplo. Esta es una afirmación de un bloque de prueba. Siempre que leo cualquier prueba, en realidad comienzo desde estas líneas de expectativa porque son las más útiles para mí. En esta prueba, esperamos que el contenido del archivo sea igual a una cadena. Es bastante sencillo. Pero no es lo que hace la prueba. Porque si miramos por encima de esta línea de expectativa, vemos que hay un bucle for.

Entonces, en realidad estamos probando que cada archivo de un seguidor tenga el mismo contenido. Y aún así, eso no es suficiente porque hay otro bucle arriba. Y en realidad estamos probando todos los seguidores y todos sus archivos para que sean iguales a una cadena específica. Solo nota cuántas cosas necesitamos calcular en nuestra cabeza para entender lo que hace la única línea de expectativa.

Entonces, parece que estamos abstrayendo la complejidad, pero en realidad solo estamos agregando más complejidad a nuestras mentes para abordarla. Así que creo que un bloque de prueba es el peor lugar para volverse inteligente. Y déjame mostrarte cómo podemos rehacer esta línea de expectativa para que sea mucho mejor. Entonces, esta es la misma afirmación de antes, pero ahora se lee en una sola línea. Esperamos que todos los contenidos de los archivos sean iguales a una cadena. Eso es todo. No hay contexto adicional adjunto. Y si necesitamos saber de dónde provienen los contenidos de los archivos, simplemente podemos ir a la línea que los obtiene, y podemos ver, hey, usa una función de utilidad. Así que abstraemos esa lógica porque en realidad, esta prueba no se preocupa por cómo extraer esos contenidos. Solo se preocupa por la igualdad.

Y luego otro punto se relaciona con la estructura de las pruebas. Y déjame contarte una historia. Una vez estaba trabajando en un proyecto realmente grande, y tenía muchas pruebas. Y una de las pruebas tenía 4,000 líneas de código. Y como suele suceder, algo salió mal. Hubo un problema y la integración continua comenzó a fallar. Así que me metí en esto e intenté averiguar qué estaba pasando. Y vi que esta prueba estaba fallando. Esta afirmación estaba fallando. Y pasé un par de minutos, y media hora, luego una hora, y simplemente no tenía sentido para mí. Porque, bueno, era como decir espero que 1 sea igual a 1, y era falso. No tenía sentido. Pero finalmente descubrí que un par de miles de líneas por encima de esa afirmación fallida, antes de OBLOCK, estaba mutando completamente el resultado de todo el sistema, y no estaba muy contento al respecto. Pero me enseñó una regla importante. Es que deberíamos intentar escribir pruebas que aún tengan sentido a las 3 a.m. Porque, imagina, es la mitad de la noche y el deber del paginador te despierta y la producción está fallando.

Entonces, abres tu computadora portátil y lo primero que haces es ir a la prueba, que esperemos que esté allí, y tratas de averiguar qué está fallando y cuál es la intención, cómo se supone que debe funcionar. Pero si tienes muchas afirmaciones inteligentes que calcular en tu cabeza, si tienes una configuración de prueba complicada, si tienes este resultado mutable del sistema, vas a tener un momento muy difícil depurando todo eso. Así que terminarás frustrado, cerrarás tu computadora portátil y te irás a la cama, y esta será una experiencia horrible que podrías haber evitado.

Y puedes evitarlo manteniendo tus pruebas planas. Aquí tienes un ejemplo para ti. Esta es una prueba típica, así que tenemos un bloque describe que envuelve toda la característica, prepara un entorno antes de todas las pruebas, luego tiene una subcaracterística, por ejemplo, y tiene su propia configuración, y finalmente, la prueba. Incluso en este ejemplo simple, nota cuántas cosas necesitamos tener en cuenta solo para entender lo que necesita esta única prueba. Entonces, ¿por qué no ponerlo directamente en la prueba y eliminar por completo los bloques describe? Y te entiendo, al principio puede ser bastante confuso y repetitivo, pero con el tiempo, llegarás a amarlo, porque los beneficios que esto brinda son increíbles. Es declarativo, es explícito y comprendes lo que cada prueba necesita de la prueba, al leer la prueba. Y luego, por supuesto, puedes crear y reutilizar utilidades de prueba para abstraer la lógica comúnmente utilizada. Por ejemplo, si en esta prueba completamos un formulario de inicio de sesión y hacemos esto muy a menudo para probar la función de inicio de sesión, bueno, ¿por qué no abstraerlo en una utilidad auxiliar y llamarlo iniciar sesión? Y nota cómo esto se lee mucho mejor de inmediato, se lee como la intención, queremos iniciar sesión con estas credenciales. No importa cuáles sean los selectores de formulario, cuáles son las ideas y las clases, no importa, la intención es iniciar sesión y luego hacer algunas expectativas.

Y, por supuesto, una de las características o enfoques más pasados por alto es que puedes dividir las pruebas, no tienes que meter todas las pruebas en un solo archivo de prueba. Entonces, si tienes una característica complicada como esta de inicio de sesión y tiene diferentes proveedores como correo electrónico y GitHub, bueno, ponlos en archivos de prueba separados y te dará una gran legibilidad y descubribilidad sin costo alguno. Y luego, cuando necesites agregar más lógica y más pruebas, simplemente agrega nuevos archivos de prueba y eso es todo. Lo mismo ocurre cuando se eliminan características, porque al igual que un buen código, una buena prueba es aquella que se puede eliminar fácilmente. Es la prueba que no introduce muchas dependencias implícitas y todo tipo de magia en la configuración, lo que hace que sea muy difícil de eliminar.

Entonces, para resumir, al abordar la complejidad en las pruebas, es muy importante utilizar adecuadamente las fases de prueba y realizar la mayor parte del trabajo pesado en la fase de configuración. Y luego, por supuesto, reducir la repetición en la fase de acción. Es realmente crucial expresar las intenciones utilizando funciones auxiliares como la función de inicio de sesión que acabo de mostrarte para ayudar a que tu prueba se lea como una especificación en lugar de un montón de detalles de implementación. Es realmente bueno mantener la estructura de las pruebas plana, por lo que quizás poner todo lo que una sola prueba necesita en un solo bloque de prueba y, por supuesto, utilizar afirmaciones explícitas y simples para que no tengas que calcular muchas cosas en tu cabeza para entender lo que hace la prueba. Y cuando se trata de características complejas, también puedes dividirlas en el nivel del sistema de archivos y obtener esta gran capacidad de descubrimiento y gran mantenimiento a medida que se desarrolla tu producto. Por supuesto, hay mucho más sobre la complejidad, pero eso es todo lo que tengo por hoy, así que asegúrate de seguirme en Twitter si te gustó esta charla y comparte conmigo algunas de tus experiencias sobre cómo lidiaste con la complejidad en las pruebas en el pasado. Espero que disfrutes esto y que tengas un buen día.