React

Test-Driven Development

# Test-driven front-end development

> Este artículo fue publicado originalmente en la edición de 2020 de
> [Octuweb](https://octuweb.com/test-driven-front-end-development/).

En la edición de 2018 **Cristina Ponce** publicó
[Testing en el front](https://octuweb.com/testing-front/), una guía sobre los
diferentes tipos de pruebas que podemos realizar en aplicaciones front-end.
Apoyándonos en ese artículo, vamos a hablar aquí de cómo aprovechar la nueva
generación de herramientas para alcanzar flujos de desarrollo que, hasta hace
solo unos años, no eran (tan) fácilmente aplicables en este contexto:
**Test-Driven Development** (o **TDD**).

## Pero primero, ¿qué es TDD?

Test-Driven Development es una metodología que se basa en aplicar pequeños
ciclos de desarrollo con el objetivo de resolver casos de prueba. De manera más
concreta, lo podemos definir en 3 pasos:

1. Codificar una prueba que defina el nuevo comportamiento que queremos añadir a
   nuestro sistema
2. Escribir la menor cantidad de código posible que nos permita hacer pasar el
   test anterior
3. Mejorar el código anterior utilizando las pruebas como red de seguridad
   (a.k.a _refactoring_)

En TDD clásico, lo habitual es comenzar por las entidades más internas de
nuestro sistema para ir construyendo capas una encima de otra hasta terminar de
implementar la funcionalidad. En front-end sin embargo, y con las herramientas
actuales, lo más natural es utilizar una variación denominada **ATDD**
(inspirada en **Outside-in**, un enfoque de TDD que se originó en la comunidad
de eXtreme Programming de Londres), donde se empieza creando un primer test en
la capa más externa del sistema (en este caso, la interfaz o un componente) para
ir construyendo desde ahí el resto de la funcionalidad.

## Escribiendo nuestro primer test

En su sentido más estricto, TDD es una herramienta de desarrollo (un flujo de
trabajo, una metodología) y no tiene que verse como un instrumento de calidad
(entendiendo esta como la disciplina para el control de defectos). Por tanto, su
objetivo es ayudar a las programadoras a entregar valor lo antes posible, con
confianza. En ATDD, por ejemplo, el primer test nos tiene que permitir poner el
foco en el problema que vamos a resolver y servirnos como guía durante el
desarrollo de la funcionalidad. Lo habitual es intentar reflejar en este primer
test los criterios de aceptación que perseguimos cumplir con la historia de
usuario en curso.

Por ejemplo, supongamos que estamos trabajando en el front-end para la web de
una editorial de libros y queremos añadir una página de contacto:

> Es posible acceder a una página de contacto para, indicando email, asunto y
> mensaje, ponerse en contacto con la editorial. Una vez completada la
> operación, se realizará una redirección a una página de éxito con un mensaje
> que indique que todo ha ido bien.
>
> Hay disponible un endpoint `/api/contact` que completa la operación en el
> back-end.

Utilizando [**Cypress**](https://www.cypress.io/), podemos trasladar esta
descripción a una prueba de alto nivel como la siguiente:

```tsx
// Location: cypress/integration/sendContactMessage.test.ts

context("sendContactMessage", () => {
  specify("A user can send a contact message", () => {
    // Setup
    cy.server();
    cy.route2("/api/contact", { statusCode: 200 });

    // Act
    cy.visit("/contact");
    cy.findByLabelText(/tu email/i).type("hola@codecoolture.com");
    cy.findByLabelText(/asunto/i).type("Información sobre próximos libros");
    cy.findByLabelText(/mensaje/i).type(
      "Hola, me gustaría obtener más información sobre próximos libros.",
    );
    cy.findByText(/enviar/i).click();

    // Assert
    cy.url().should("eql", Cypress.config().baseUrl + "/contact/success");
    cy.findByText(/tu mensaje ha sido enviado con éxito/i).should("exist");
  });
});
```

La prueba anterior codifica el escenario de aceptación básico: primero, hacemos
que Cypress simule la respuesta al endpoint `/api/contact` para indicar que todo
ha ido bien (devolverá un código `200`), y después interactuamos con la
aplicación para ir a la página de contacto y completar el formulario. Por
último, validamos que se ha llevado al usuario a la página de éxito tras enviar
el formulario.

> Ahora que hemos visto un ejemplo, seguramente nos sea más sencillo explicar
> qué es Cypress: un framework de testing para construir pruebas de aceptación
> sobre un navegador, utilizando JavaScript.

En el ejemplo anterior, la prueba se ejecutará sobre nuestra propia aplicación.
En este caso, **como todavía no hemos escrito código de producción, lo que
esperamos es que el test falle**. Es ahora cuando tenemos que escribir la mínima
cantidad posible de código para que este test pueda pasar.

```tsx
// Location: pages/contact.tsx

export default function Contact() {
  return (
    <main>
      <Formik
        initialValues={{ email: "", subject: "", message: "" }}
        onSubmit={async ({ email, subject, message }) => {
          const response = await fetch("/api/contact", {
            body: JSON.stringify({ email, subject, message }),
            headers: { "content-type": "application/json" },
            method: "post",
          });

          if (response.ok) {
            window.location.href = "/contact/success";
          }
        }}
      >
        {() => {
          return (
            <Form>
              <label>
                Tu email <Field id="email" name="email" />
              </label>

              <label>
                Asunto <Field name="subject" />
              </label>

              <label>
                Mensaje <Field name="message" />
              </label>

              <button type="submit">Enviar</button>
            </Form>
          );
        }}
      </Formik>
    </main>
  );
}
```

```tsx
// Location: pages/contact/success.tsx

export default function ContactSuccess() {
  return <p>¡Enhorabuena! Tu mensaje ha sido enviado con éxito</p>;
}
```

Obviando algunos detalles de implementación (como el uso de
[Formik](https://formik.org/) para el formulario), los dos fragmentos de código
anteriores muestran una posible implementación (básica pero funcional) que sirve
para hacer pasar nuestro primer test de aceptación. En este punto, podemos
añadir CSS a nuestra nueva página o extraer comportamientos a otro tipo de
entidades (por ejemplo, mover la operación de `onSubmit` a un servicio). Si
nuestro test sigue en verde al completar los cambios, tendremos la certeza de
que no hemos roto nada ✅

## Aplicando ciclos de desarrollo más pequeños

Aunque Cypress es un magnífico framework de testing, las pruebas de tan alto
nivel suelen venir con algunos compromisos: es difícil poder ejercitar todos los
caminos de ejecución posibles y son lentas. Recordad que con TDD estamos
buscando mejorar nuestra productividad por lo que **necesitamos que los ciclos
de feedback sean lo más cortos posibles**. Para ello, mi consejo es utilizar
pruebas de aceptación para cubrir el _happy path_ de la funcionalidad (y quizás
algún escenario de error clave) y después iterar en ciclos de desarrollo más
pequeños facilitados por pruebas de una granularidad más baja (en front-end,
podríamos entenderlas como híbridos de integración + unitaria, centradas en
componentes).

Si volvemos al ejemplo anterior, seguramente hay ciertas reglas de experiencia
de usuario que queramos validar sobre el formulario de contacto: que no se pueda
completar la operación sin un email de remite o sin el cuerpo del mensaje, que
aparezcan correctamente los mensajes de error, que los campos permitan
únicamente ciertos patrones, etc. Aunque estas pruebas se podrían hacer también
utilizando Cypress, su latencia es a menudo lo suficientemente grande como para
preferir moverlos a tests de más bajo nivel (por lo general, más rápidos).

Para hacer pruebas de componentes (en React, aunque las mismas herramientas
están disponibles en otros frameworks como Vue o Angular) mi consejo es utilizar
[**Testing Library**](https://testing-library.com/) en conjunción con
[**Jest**](https://jestjs.io/). Por ejemplo, vamos a añadir un nuevo
comportamiento a nuestra página de Contacto, aunque esta vez iterando en un
nivel de abstracción más bajo:

> El formulario sólo debe enviarse si contiene un email de remite y un mensaje.

```tsx
// Location: components/ContactForm.test.tsx

describe("ContactForm", () => {
  it("does not submit the form if some required fields are missing", async () => {
    // Setup
    const spy = jest.fn();
    render(<ContactForm onSubmit={spy} />);

    // Act
    await user.type(
      screen.getByLabelText(/asunto/i),
      "Información próximos libros",
    );

    user.click(screen.getByText(/enviar/i));

    // Assert
    await expect(
      screen.findAllByText("Este campo es obligatorio."),
    ).resolves.toHaveLength(2);

    await waitFor(() => expect(spy).not.toHaveBeenCalled());
  });
});
```

El test anterior codifica el nuevo comportamiento que queremos validar. Veréis
que, en un primer vistazo, la apariencia del test es similar al primero que
creamos utilizando Cypress. La única diferencia es que aquí se prueba el
componente de manera aislada en lugar de simular a un usuario real utilizando la
aplicación. En Testing Library, no hay ningún navegador ejecutándose en
paralelo, como sí ocurre con Cypress; así, mientras el último que hemos escrito
podemos ejecutarlo en ~2 segundos, el primero necesita de ~22 segundos.

Cuando trabajamos a un nivel de granularidad más bajo, nuestros tests pueden
afectar al diseño de nuestros componentes (por lo general, haciéndolos más
sencillos de probar). En este caso, he decidido inyectar la función que gestiona
el envío del formulario para poder reemplazarla por un espía que me permita
validar que no se ha invocado cuando no debía (aunque también podríamos haber
espiado el módulo HTTP con [**nock**](https://github.com/nock/nock)). Este es
otro de los beneficios clave de TDD, ser capaces de ir definiendo el diseño de
nuestras interfaces a medida que escribimos las pruebas.

Como todos estos cambios no están repercutiendo en cambios de comportamiento a
nivel de aceptación, nuestro test de Cypress debería seguir pasando después de
cada modificación, ayudándonos de nuevo a garantizar que no hemos roto nada ✅.

Ahora, al igual que en el ejercicio anterior, tendríamos que escribir la menor
cantidad de código que sirva para hacer pasar este test.

> Pss! Podéis ver el ejemplo completo en
> [este repositorio de GitHub](https://github.com/codecoolture/octuweb-2020) 👀

## Conclusión

¿Que conseguiremos aplicando un flujo similar al anterior? En la literatura de
TDD, estaríamos aplicando lo que se conoce como
[Outside-In development with Double Loop TDD](http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/)
o el proceso descrito en el libro
[Growing Object-Oriented Software, Guided by Tests](https://www.goodreads.com/book/show/4268826-growing-object-oriented-software-guided-by-tests).

Primero, arrancamos con un test de aceptación (o del nivel de granularidad más
alto que podamos) que nos ayudará a mantener el foco en la funcionalidad que
queremos resolver. En ocasiones, este test puede estar fallando durante varias
horas porque necesite de otros ciclos complementarios más pequeños que nos
ayuden avanzar (el ejemplo anterior era tan sencillo que no lo hemos
necesitado). Para esos ciclos complementarios es donde podemos hacer uso de
flujos como TDD clásico (útil para avanzar en piezas de bajo nivel como
funciones, clases, servicios) y herramientas como Testing Library (para probar
los diversos componentes que construyan la interfaz) o _simplemente_ Jest (para
lógica de negocio como controladores, funciones de utilidad, etc.).

## Otras referencias

- Además de los enlaces contenidos en el artículo, podéis encontrar más
  referencias a TDD en
  [esta página](https://www.notion.so/codecoolture/Public-References-50b1e927fe1641748f95610353e97b7f).
- Cypress tiene una sección de
  [mejores prácticas](https://docs.cypress.io/guides/references/best-practices.html)
  con algunos consejos muy útiles sobre cómo escribir pruebas de aceptación.
- [Kent C. Dodds](https://twitter.com/kentcdodds/) (creador de Testing Library)
  tiene bastantes artículos relacionados con testing de aplicaciones front-end
  (desde TDD hasta diferentes estrategias de testing). Podéis encontrarlos en
  [su blog](https://kentcdodds.com/blog?q=testing).


Test-driven front-end development

# Aplicando ATDD para resolver El Juego de la Vida

> Nota: en la literatura, ATDD suele ir acompañado de un conjunto de prácticas y
> herramientas más amplio que lo descrito en este artículo. Mi objetivo aquí es
> transmitir mi experiencia sobre cómo aplicar parte de sus principios para
> mejorar nuestra productividad a la hora de resolver determinados problemas,
> visto únicamente desde el plano de desarrollo de software.

Una de las situaciones más habituales que me he encontrado en los últimos años
cuando facilito coding dojos o coderetreats (donde muchas personas se enfrentan
por primera vez a resolver una _kata_ aplicando metodologías como TDD) es
observar cómo los participantes empiezan atacando el problema de una manera que
no les ayuda a avanzar, sino más bien les obliga a perderse en pequeños detalles
de implementación o incluso a sufrir de cierta _parálisis por análisis_.

Al principio, yo también pensaba que aplicar TDD debería ser suficiente por sí
mismo para evitar esa fricción inicial y tener _working software_ lo más rápido
posible, pero tras observarlo (y sufrirlo) durante varios años, me he dado
cuenta que no siempre es así. Cuando empezamos a trabajar con TDD es habitual
que tratemos de solucionar el problema desde aquellos puntos donde nos es más
sencillo poder aplicarlo (pequeñas piezas de bajo nivel, como una función
sencilla), aunque no sean las partes que nos ayuden a llegar antes a resolver el
problema (y por tanto, a entregar valor).

Como parte de la preparación para facilitar el
[GDCR19](https://www.coderetreat.org/), estuve trabajando en resolver el Juego
de la Vida utilizando un enfoque basado en
[ATDD](https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven_development)
(_acceptance test-driven development_), una aplicación de TDD que nos obliga a
pensar en pruebas de muy alto nivel (aceptación) con la idea de tener una
versión desplegable de nuestro sistema con cada iteración.

## El síndrome de la página en blanco, o _ese_ primer test

Una de las ventajas de aplicar ATDD es que esa primera _crisis_ sobre cómo
atacar el problema me vino resuelta casi de base. En este caso, sabía que el
sistema debía ser un CLI que, a partir de un fichero de entrada, generase un
fichero de salida con la siguiente evolución del tablero
([aquí](http://codingdojo.org/kata/GameOfLife/#problem-description) tenéis un
enlace con las reglas del juego).

La primera porción de funcionalidad mínima (de alto nivel) que se me ocurrió
implementar fue un CLI que, dadas las condiciones anteriores, supiera
evolucionar un tablero con despoblación.

Seguramente, esta sea la diferencia más notable frente a tratar de resolver el
problema utilizando (únicamente) TDD a nivel unitario (de ahora en adelante,
UTDD -aunque no creo que este concepto esté definido en ningún sitio 😅). Con
UTDD nos vemos _obligados_ a detectar desde el principio una primera entidad
sobre la que escribir los tests, lo que en muchas ocasiones me ha hecho perder
el foco y caer en la trampa del
[Big Design Up Front](https://wiki.c2.com/?BigDesignUpFront).

```ts
const subject = join(__dirname, "../src/cli.ts");

it("supports underpopulation", () => {
  const inputFilename = join(__dirname, "./fixtures/underpopulation");
  const outputFilename = join(__dirname, "./results/underpopulation");

  play(`${subject} --input=${inputFilename} --output=${outputFilename}`);

  const result = getResult(outputFilename);

  expect(result).toEqual(["0 0 0", "0 0 0", "0 0 0"].join("\n"));
});
```

Pero vayamos paso a paso por el test anterior:

- La función `play` es un simple envoltorio que ejecuta en un shell la
  instrucción indicada. En este caso, nuestro ejecutable es el fichero
  `src/cli.ts` y se le pasan como parámetro ambos: el fichero de entrada con el
  tablero inicial y el fichero de salida donde guardar la evolución.
- Una vez ejecutado el script, recuperamos el resultado a partir del fichero de
  salida indicado y comprobamos que sea el resultado esperado.

ATDD sigue el mismo ciclo Red-Green-Refactor que TDD, por lo que en esta primera
iteración hemos sentado las expectativas tanto de un primer comportamiento del
sistema como de su propia interfaz para operar, sin tener aún nada de código de
producción implementado. Si estáis acostumbradas a trabajar con UTDD, es posible
que este primer test os parezca _demasiado grande_. Y es que con ATDD el **ciclo
de feedback** es mucho más largo.

## Añadiendo nuevos comportamientos

Con el test anterior en verde, ya dispondríamos de una versión 0.1.0 de nuestro
Juego de la Vida 🙂 Un CLI que, a partir de un fichero de entrada, sería capaz
de evolucionar el tablero detectando aquellas células que sufran de despoblación
y guardando el resultado en el fichero de salida indicado.

Pero para implementar el Juego de la Vida de manera completa, hay que tener en
cuenta también otros escenarios. El enfoque que apliqué para ello fue ir creando
un nuevo test para cada nuevo comportamiento. Así pues, tras implementar el
soporte para despoblación, el siguiente en la lista era el escenario de
sobrepoblación.

Con esa prueba también en verde, tendríamos una nueva versión 0.2.0 del sistema
lista para desplegar; esta vez, soportando ya un nuevo escenario. Este mismo
flujo se utilizaría para implementar el resto de reglas.

> Cada nuevo test define un nuevo comportamiento de alto nivel en el sistema. Al
> resolverlo, nuestro software debería estar listo para ser desplegado.

## ATDD y productividad

Seguramente, aplicar ATDD tampoco me hubiese ayudado a terminar de implementar
el Juego de la Vida en los 45 minutos que duran las sesiones de un coderetreat
🙃, pero sí creo que me habría permitido acercarme mucho más que si hubiese
intentado solucionar el sistema siguiendo una estrategia _bottom-up_.

Trabajar con tests de aceptación me ayudó a ganar foco y programar rápidamente
una solución que los pusiese en verde. Sentir que con cada prueba disfrutas de
un sistema desplegable (aunque su implementación no sea perfecta a nivel de
diseño) me parece un gran _boost_ de productividad. Con 4 pruebas, tienes las
reglas de negocio del Juego de la Vida cubiertas y puedes empezar a aplicar
_refactoring_ para extraer comportamientos a nuevas entidades de manera muy
confiable (los test de aceptación te aseguran que el sistema funciona punto a
punto -y esto, cuando sueles trabajar con muchos pequeños tests unitarios, está
muy bien).

## ATDD y UTDD

El Juego de la Vida es un problema sencillo, que prácticamente se resuelve con
unas pocas líneas de código. En sistemas más sofisticados, donde estemos
implementando funcionalidad más compleja, es muy habitual mezclar ambos ciclos
para disfrutar de las ventajas de ambos enfoques (lo más habitual es que
trabajemos con código _legacy_, donde aplicar UTDD es _sencillo_ al tener muchas
entidades de dominio ya modeladas en nuestro sistema).

Juntar ambas estrategias termina generando un _ciclo de ciclos_, donde el test
de aceptación está en rojo mientras que vamos aplicando ciclos de UTDD para
tratar de ponerlo en verde (y terminar de implementar ese nuevo comportamiento
de alto nivel en el sistema).

## Contenido relacionado

Si os habéis quedado con ganas de investigar un poco más, el libro
[Growing Object-Oriented Software, Guided by Tests](https://www.amazon.es/Growing-Object-Oriented-Software-Addison-Wesley-Signature-ebook/dp/B002TIOYVW)
cubre muy bien (y en profundidad) esta manera de trabajar y resolver los
problemas. Además, he publicado en
[GitHub](https://github.com/sergioalvz/practice/tree/master/game-of-life-atdd)
la implementación que utilicé para practicar con este enfoque mientras resolvía
el Juego de la Vida.

La estrategias comentadas en este artículo también se representan en la
literatura a través de los conceptos de **Inside Out** y **Outside In** (que se
cubren en detalle en
[este artículo](https://8thlight.com/blog/georgina-mcfadyen/2016/06/27/inside-out-tdd-vs-outside-in.html)).


Aplicando ATDD para resolver El Juego de la Vida

# Introducción a TDD en AsturiasHacking

Los pasados días
[4 y 5 de abril impartí mi primer taller de introducción a TDD](https://www.meetup.com/AsturiasHacking/events/258852355/)
en AsturiasHacking. Después de varios años (co-)organizando esta comunidad,
tenía claro que el tema levantaba cierto interés entre los participantes, que
siempre intentaban algún tipo de aproximación cuando realizamos actividades
prácticas (como el [Global Day of Coderetreat](https://www.coderetreat.org/)).

Mi objetivo para el taller era introducir _test-driven development_ desde una
perspetiva nada dogmática, basada en mi experiencia y donde quedara evidente que
se trata de otra herramienta más, útil especialmente de cara a diseñar software
y **poco efectiva** de cara a realizar labores exhaustivas de _quality
assurance_.

La manera de organizar el taller se dividió en dos tardes, con dos horas de
duración cada sesión. Durante el primer día realizamos una introducción teórica
a la metodología: cuáles son sus "normas" y beneficios. Para después dedicar un
rato a programar en parejas para poder aplicar los conceptos aprendidos.

El segundo día, sin embargo, lo aprovechamos para discutir diferentes
estrategias para enfrentarnos a código _legacy_ y cómo relacionar nuestro código
con el resto de colaboradores de un sistema ya en producción. Para ello,
introdujimos el concepto de _test doubles_, con sus diferentes tipos y
propósitos, para terminar con una parte práctica donde los participantes debían
enfrentarse a un código sin pruebas, con un diseño muy acoplado y sobre el que
realizar una pequeña extensión de su funcionalidad.

El feedback sobre la sesión fue muy positivo. Por ejemplo, las siguientes citas
ilustran bastante bien las conclusiones que salieron en el _closing circle_:

> He aprendido, más bien descubierto, una nueva forma de afrontar o aproximarme
> a la creación de código nuevo.

> Me ha sorprendido la forma real de usar TDD ya que sí creía que era únicamente
> \[hacer\] tests.

> Me ha sorprendido como trabajar en pequeños pasos ayuda a centrarte en el
> problema.

En este enlace os dejo
[un documento con todos los recursos y bibliografía](http://bit.ly/2U6e5fo)
utilizados durante la sesión.


Collection: Test-Driven Development

2020

2019

Browse all collections