Cómo las pruebas de software pueden contribuir a la comunicación

Las pruebas de software pueden mejorar la comunicación y ahorrar tiempo (y frustración). Las malas pruebas pueden hacer lo contrario. En este artículo analizaremos un ejemplo de la vida real de cómo las malas pruebas son perjudiciales y cómo las buenas transmiten la información correcta.

Un cuento sobre un título

En Vividnecesitábamos añadir un título a nuestro botón. No es que el botón no tuviera uno. Vivid es una librería basada en componentes web, y dentro de nuestro elemento botón, hay un botón nativo oculto bajo el Shadow DOM.

Este botón nativo no recibía el título de su padre, lo que era malo para la accesibilidad de nuestro sitio web (basado en a11y ).

Así que... la tarea era bastante sencilla. Obtener un título del host (el elemento personalizado) y reflejarlo en el botón interno. Así de fácil:

Utilizaremos este ejemplo y seguiremos su ruta de commit para comprender y aprender a evitar errores sencillos en las pruebas.

Lección nº 1: Cambiar la interfaz es una señal de alarma

El primer commit en este Pull Request se entrometió con la interfaz. Aquí está el cambio en la prueba:

Esto hizo que las pruebas fallaran. Puede ver que la prueba cambió de toBeFalsy a "ser igual a una cadena vacía". ¿Qué pasa con esto?

Hay tres errores en este caso:

• toBeFalsy puede ser muchas cosas (cadena vacía, null, undefined, NaN, 0 y false), pero a diferencia de una cadena vacía, no es indefinida.

• La interfaz no estaba suficientemente bien documentada, porque toBeFalsy es demasiado amplia.

• Por alguna razón, la interfaz se cambió a '' en la prueba. ¿A qué se debe? ¿Es un cambio de última hora?

Aquí, la trama se complica. Estos dos errores son sólo el aperitivo de una pérdida de 24 horas de desarrollo. Vayamos al plato principal.

Cómo unas malas pruebas conducen a un mal código

Mientras intentaba ayudar a resolver la prueba fallida, estaba de regreso de unas vacaciones.

Miré el código de prueba usando mi teléfono y vi que la interfaz documentada implicaba que el valor del título debía ser una cadena vacía.

"¡Pues claro que falla! El valor inicial no es una cadena vacía. Ponlo como cadena vacía y funcionará".

El cambio fue bastante fácil. Basta con establecer el valor en el constructor, y la prueba pasará:

Esta corrección empeoró el problema que vimos en el primer error. No sólo cambiamos la documentación, sino también la interfaz real. Sí, las pruebas pasaron, pero ¿era la prueba correcta? ¿Y cómo una cosa tan sencilla nos ha costado 24 horas de trabajo? Vayamos al segundo error.

Error nº 2: No pasarás (por la razón correcta)

El cambio de interfaz era sólo el primer paso. Había lógica real para implementar, ¿verdad? Aquí está la prueba para la próxima implementación:

Lo primero que aparece es la descripción de la prueba. La errata (falta el conjunto después del no) es el error más destacado, pero hay algo más.

La descripción está escrita en negativo. En ciencia no se puede demostrar que algo no existe. Como el software entra dentro de la informática, podemos verlo de la misma manera. No me digas lo que no debe hacer, dime lo que debe hacer.

Dos cosas aún peores que la descripción están en el propio código de prueba. Tómate un minuto para ver si las encuentras.

...

...

Bien, ya ha pasado el minuto. Has encontrado uno o dos errores más?

Razón equivocada nº 1: Probar la cosa equivocada

Mencioné al principio que nuestra misión era establecer el título en el botón interno. Esta prueba no describe ese escenario.

¿Puede ver que la prueba se realiza en el elemento, y no en el botón interno? Cuando leí la prueba, supuse que el autor quería que el título apareciera en el elemento. Esa es la documentación. Y eso es lo que espero que haga el componente.

Razón errónea nº 2: Las expectativas no coinciden con la descripción

Otra cosa es que la expectativa en esta prueba es tener un título con una cadena vacía. Lo que queremos conseguir es totalmente distinto: queremos eliminar el atributo title en ese caso.

Pasaron 12 horas, y yo estaba de vuelta en casa de mis vacaciones, pensando en cómo implementar el código para cumplir con la especificación dada.

Algunos mensajes de Slack confirmaron mis sospechas: el atributo title debe eliminarse cuando el título es falso. No dudé ni un minuto de que el título no debía establecerse en el elemento.

He cambiado un poco la prueba para asegurarme de que vamos por el buen camino:

t

Ahora, la expectativa es eliminar realmente el atributo.

Para que pasara, tuve que cambiar algunas cosas en la plantilla y en la clase del componente. En la clase, tuve que anular el atributo title (nuestro elemento Class extiende otro elemento básico Class). También tuve que establecer un convertidor que establece el valor a null en la plantilla si el valor es falso, pero dejarlo como una cadena si se cambia desde la propia vista:

Todo funcionó como se esperaba. Empujé y esperé los elogios de la autora de Relaciones Públicas sobre cómo le había salvado el día. ¿O no?

La comunicación es la clave

El esperado mensaje de Slack llegó unas horas más tarde. Sin embargo, el mensaje en sí era menos esperado:

Espera, ¿¡WAT!?

Y así comenzó otra correspondencia en Slack. Fue breve, pero al final, esa fue mi opinión:

Me quedé de piedra cuando se supo que el problema estaba en el botón interno.

El arreglo, como era de esperar, fue mínimo. Tuve que hacer la prueba tanto en el elemento como en el botón interno (a este tipo de elementos los llamamos "elementos de control"):

Ahora que teníamos una prueba en su lugar, también podría asegurarse de que nuestro valor inicial será más específico y de acuerdo con la especificación HTML (null):

Este sencillo arreglo nos llevó 24 horas (sí, ya sé que estuve de vacaciones la mitad de ese tiempo, pero las excusas son para los débiles 😉 ). Se podría haber ahorrado con mejores pruebas o mejores habilidades de comunicación por mi parte.

Conclusión

Redactar buenas pruebas

Se supone que las pruebas fallan cuando el código no hace lo que se supone que debe hacer. Las pruebas también deben ser una descripción directa de cómo funciona el código. Si la prueba dice que un título debe estar en el elemento, entonces estas son las instrucciones para el implementador.

La interfaz también está protegida por pruebas. Si la prueba no protege la interfaz correctamente o de forma suficientemente estricta (como en el caso de la prueba toBeFalsy en lugar de toBeNull aquí), entonces no sabemos realmente qué esperar como desarrolladores y consumidores de la interfaz. Puedes leer más sobre la importancia de las pruebas de interfaz en mi post, Un cuento de implementación y detalle.

Escribir pruebas para comunicar

Una buena capacidad de comunicación es importante. No todo el mundo las tiene. Especialmente en entornos de trabajo remotos. Si hubiéramos codificado juntos en persona, esto no habría llevado tanto tiempo. Nuestro equipo trabaja a distancia (un equipo internacional), y la comunicación suele ser "asíncrona", lo que significa que suele haber un retraso en la respuesta.

Escribir las pruebas correctamente, con una descripción clara y una lógica que describa cómo deben ser las cosas ayuda a mitigar esos errores de comunicación en el equipo.

Únete a la conversación en nuestro Slack de la comunidad de Vonage o envíanos un mensaje en X, antes conocido como Twitter.