Given when then. Las partes de un test.

Hablemos de Gherkin.

Sí, ese lenguaje para describir casos de uso de las aplicaciones de manera natural.

En esencia, la descripción de un caso consta de tres partes denominadas Steps: Given When Then (en castellano Dado, Cuando, Entonces).

Hablemos de Cucumber. Sí, esa herramienta que permite convertir los pasos de Gherkin en pruebas ejecutables. Es extremadamente útil para aprender a diseñar nuevos tests.

Y, ¿por qué? Porque ese trío de palabritas (Given, When, Then), es literalmente como funcionan el qa testing.

¿Qué significa Given When Then?

Given When Then significa en software testing los 3 pasos de un test.

• Given (Dado): ¿en qué situación queremos probar la funcionalidad?

• When (Cuando): ¿qué acción del usuario queremos probar?

• Then (Entonces): ¿cuál es el resultado esperado?

Lo más sencillo es ver un ejemplo:

Dado que el usuario tiene algún producto en el carrito
Cuando el usuario proceda a la compra
Entonces la página le mostrará la pasarela de pago

Y aquí el secreto: esta estructura no sólo es la base de todo buen test, ¡sino de toda la informática!

El origen de Given When Then: Arrange, Act, Assert

En el principio creó Dios los cielos y la tierra. Pero como el cielo no dejaba de caerse, también creó los test unitarios. Cuatro parches y un rollback más tarde, todo ha quedado más o menos estable.

Existe un mantra en el mundo de los tests unitarios: Arrange, Act, Assert. O, en castellano: Preparar, Actuar, Validar.

Momento del ejemplo:

describe("Carrito de la compra", () => {
    it("actualiza el valor total al añadir un nuevo item", () => {
        // Preparar
        let carrito = new Carrito();
        carrito.add(patatas);
        let total_inicial = carrito.total();

        // Actuar
        carrito.add(elefante);

        // Validar
        assert.equal(carrito.total(), total_inicial + elefante.precio);
    });
});

Así que entendemos los diferentes pasos de la siguiente forma:

• Preparar (Given): organizamos lo necesario para obtener el punto de partida de nuestro test.

• Actuar (When): realizamos la llamada o llamadas a función que estemos probando

• Validar (Then): comprobamos que el comportamiento de la función corresponde a lo esperado

Estos tres sencillos pasos corresponden a las buenas prácticas de los tests unitarios y, como vemos, se asemejan mucho al Given When Then de Gherkin.

Este hecho es pura casualidad y definitivamente no tiene ninguna relación con cómo funcionan los ordenadores… ¿Verdad?

Conexión con la teoría de la computación: Máquina de estado finito

Hablemos de teoría de la computación. No, por favor, no hace falta que salgas corriendo, en serio que esto es interesante.

Los ordenadores de hoy en día se encargan de realizar operaciones computables. ¿Qué es una operación computable? Algo que puede resolver una Máquina de Turing.

¿Qué es una Máquina de Turing? Básicamente una Máquina de estado finito. Este concepto, aunque teórico, tiene aplicaciones prácticas directas en cómo diseñamos y probamos software, reforzando la relevancia de Given, When, Then.

Mira cómo representamos una máquina de estados:

Cada círculo representa un estado que puede tener la máquina, y cada arista representa una transición que puede hacer hacia otro estado. Y si nos fijamos en las transiciones de la máquina (es decir los cambios que se producen y, por tanto, la funcionalidad de la misma) podríamos describirlos de la siguiente manera.

1. Estado inicial

2. Transición elegida

3. Estado final

Y si quisiéramos comprobar que una transición (funcionalidad) se comporta como debe, haríamos algo como:

1. Preparar: vamos al estado inicial

2. Actuar: ejecutamos la transición

3. Validar: comprobamos que estemos en el estado final

O, dicho de otra manera:

Dado que estamos en el estado inicial
Cuando ejecutamos la transición
Entonces llegamos al estado final

Un test en tres partes: Given When Then.

Ya sea que lo llamemos Arrange, Act, Assert o Given When Then; al final para realizar un buen test es importante tener los tres aspectos mencionados bien definidos y claros.

Si no definimos bien el estado inicial de nuestro test, podemos tener que lidiar con efectos secundarios inesperados que vengan del estado de la aplicación.

Si no definimos bien la acción que llevamos a cabo, podemos no llegar exactamente al estado final que deseamos.

Si no definimos bien el estado final, podemos creer equivocadamente que el test ha tenido éxito o ha fracasado.

Así que siempre que escribas un nuevo test, sigue la siguiente lista de tareas:

1. ¿En qué estado necesito que esté mi aplicación para realizar este test? Escríbelo.

2. ¿Qué acción exacta es la que quiero comprobar? Escríbela.

3. ¿Cómo puedo asegurar que el resultado de la acción me lleva exactamente al estado que espero? Escríbelo.

4. Asegura que los tres pasos anteriores son claramente visibles y comprensibles en tu test.

La siguiente persona que lea tu test (¡que quizás seas tú cuando en 3 meses ya no recuerdes nada de lo que hiciste!) te lo agradecerá eternamente.

Para más insights sobre este tema, recientemente exploramos Given When Then en un streaming de YouTube, proporcionando una visión más profunda de su aplicación práctica en el testing de software."

Ahora que ya sabes el por qué de las 3 partes de un test, descubre si tests de software son tan malos como crees, en nuestro blog.

Si desear mejorar tus habilidades como qa tester, puedes descargar nuestro ebook gratuito o venir a visitarnos