# Testing the unexpected

Imagine you are coding a new React component to upload a file. The component will receive a callback to notify the app
if the upload has been or not successful. You may end with something similar to:

```tsx
/**
 * We will use the `executor` function to simulate different
 * scenarios from our tests.
 */
function UploadButton({ executor, onSuccess }) {
  return (
    <button
      type="button"
      onClick={async () => {
        await executor();

        onSuccess();
      }}
    >
      Upload
    </button>
  );
}
```

To test the most simple scenario, that the `<UploadButton />` component uses the callback once the upload completed, we
can rely on the standard approach:

```tsx
it("uses the callback to notify that the upload completed", async () => {
  const spy = jest.fn();

  render(<UploadButton executor={success} onSuccess={spy} />);

  user.click(screen.getByText("Upload"));

  await waitFor(() => {
    expect(spy).toHaveBeenCalledTimes(1);
  });
});
```

But things are more complicated if we want to ensure that the `onSuccess` callback does not get executed if something
unexpected happens and the process fails. The initial and most naive implementation might be to assure that the spy is
never called when using the failing executor:

```tsx
it("does not use the callback if something goes wrong", async () => {
  const spy = jest.fn();

  render(<UploadButton executor={fail} onSuccess={spy} />);

  user.click(screen.getByText("Upload"));

  await waitFor(() => {
    expect(spy).toHaveBeenCalledTimes(0);
  });
});
```

**Even if it passes, the test is not checking that the spy never gets called**. Since the executor is an asynchronous
process, and the spy starts with zero calls, the expectation is valid right away. You can spot this by replacing
`executor={fail}` with `executor={success}` --that's the kind of change that should make the test have a different
result, but it continues passing!

To test this scenario, we need to come up with a different approach:

```tsx
it("does not use the callback if something goes wrong", async () => {
  const asyncRender = new Promise<undefined>((resolve, reject) => {
    render(<UploadButton executor={fail} onSuccess={reject} />);

    user.click(screen.getByText("Upload"));

    setTimeout(resolve, 0);
  });

  await expect(asyncRender).resolves.toBeUndefined();
});
```

By embracing the asynchronous nature of this problem, we can wrap the rendering within a promise and use its reject
function as `onSuccess` callback. Remember that promises execute immediately but return a delayed response. To give some
room for the component to fail, I use the [setTimeout][settimeout] trick to force the process to complete pending tasks
from the queue.

Now, `asyncRender` should always resolve (with an `undefined` value). If it does not, our component is having issues
handling the `onSuccess` callback and calling it even when the upload fails (since it is what the failing executor
does). If you change `executor={fail}` by `executor={success}`, you may see the result keeps coherent, and the test then
fails.

[settimeout]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop#zero_delays


# Un acercamiento sencillo a feature flags en una aplicación React con TypeScript

Aunque ya he escrito en otras ocasiones sobre feature flags y como su uso nos puede ayudar a alcanzar un flujo de
entrega continua, en este artículo me gustaría compartir una implementación sencilla en React utilizando TypeScript.

En esencia, una feature flag es un interruptor que nos permite activar o desactivar una funcionalidad concreta bajo una
serie de condiciones. Los tipos de condiciones pueden ser muy variados: entorno de ejecución de la aplicación, tipo de
usuaria, porcentaje de tráfico, etc. Además, el cálculo de esa condición puede realizarse dentro de la propia
aplicación, o bien delegarse en otro sistema.

Este concepto posibilita, entre otras cosas, desacoplar nuestro repositorio del proceso de entrega de software. Siempre
y cuando nuestras funcionalidades incompletas estén protegidas bajo una feature flag, podremos integrar continuamente
nuestros cambios en la rama principal (aunque eso implique su despliegue a producción o cualquier otro entorno).

## Publicando feature flags

El primer paso para comenzar a utilizar feature flags es definirlas en algún sitio. Aunque existan servicios
específicamente creados para trabajar con ellas (que, además, ofrecen flujos y procesos mucho más refinados), yo siempre
recomiendo comenzar con un enfoque humilde, gestionando las feature flags directamente en la aplicación. En este caso,
vamos a crear un módulo que exporte las diferentes feature flags y una función para obtener su estado:

```tsx
export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};
```

La única razón de asociar una función a la feature flag en lugar de directamente un booleano es dotarle de cierta
flexibilidad (realmente, sería incluso más interesante hacer que la función devolviese una promesa -de esa manera,
estaríamos cubriendo el caso en el que, para calcular el valor de una feature flag, tuviésemos que realizar una petición
a un servicio externo).

## Integrando la aplicación React con las feature flags

Ahora que ya tenemos un módulo encargado de publicar las feature flags de la aplicación, es hora de hacerlo accesible
desde los componentes React.

El enfoque más directo, sería importar el módulo desde las diferentes páginas o componentes que lo utilicen y realizar
después las operaciones para mostrar/ocultar alguna parte de la interfaz. Aunque este enfoque funcionaría estaríamos
creando una dependencia no explícita entre nuestros diferentes componentes y un elemento global (el módulo de
`Features`) lo que hará que probar nuestros componentes en cada uno de los estados sea más complejo.

Vamos a verlo con un ejemplo:

```tsx
import { Features } from "../lib/Features";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {Features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

En esta implementación, `Menu` utiliza directamente el módulo de `Features` para saber si tiene que mostrar o no la
opción de ajustes. A la hora de probar este componente, tenemos que tener en cuenta esta dependencia y utilizar un
_stub_ para poder ajustarlo a ambos escenarios:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Features } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    jest.spyOn(Features, "newSettingsPage").mockImplementationOnce(() => true);

    render(<Menu />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

Los stubs (o test doubles en general) son recursos muy útiles pero me gusta reservar su uso para situaciones donde no
tengo ninguna otra opción más idiomática para probar el sujeto bajo test. En este caso, lo ideal sería convertir esa
dependencia no explícita en algo que pudiésemos controlar desde el exterior, utilizando inyección de dependencias. En
React, tendríamos varias opciones para conseguirlo. Veamos un par de ellas.

### Obtener las feature flags a través de una prop

Por ejemplo, utilizando una prop `features` para poder recibir el objeto completo de feature flags. El problema con este
enfoque es que podría haber muchos componentes intermedios que necesiten propagar esta prop sin necesidad de utilizarla.
Este fenómeno se denomina [Prop Drilling](https://kentcdodds.com/blog/prop-drilling) y, aunque no es malo _per se_,
puede convertirse en algo difícil de gestionar cuando nuestra aplicación crezca en número de componentes.

```tsx
import { Features } from "../lib/Features";

export function Menu({ features }: { features: typeof Features }) {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

Ahora que el componente `Menu` obtiene la información de las feature flags a través de una prop, podemos ajustar los
diferentes escenarios para las pruebas sin necesidad de utilizar test doubles:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu features={{ newSettingsPage: () => false }} />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(<Menu features={{ newSettingsPage: () => true }} />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

### Obtener las feature flags a través de la API de contextos

Bien utilizada, la [API de contextos de React](https://reactjs.org/docs/context.html) puede servir como un contenedor de
inyección de dependencias que permita aislar a los componentes padre de las dependencias concretas de sus componentes
hijo. En este caso, vamos a crear un nuevo contexto que publique las feature flags disponibles dentro de la aplicación y
que permita acceder a ellas a través de un hook concreto, `useFeatures`.

Lo primero, es definir el propio contexto encargado de devolver las feature flags existentes. Junto a él, también
definiremos el hook que se utilizará después desde nuestros componentes. Este último es una simple capa de abstracción
que centraliza la lógica común de acceso.

```tsx
import { createContext, useContext } from "react";

export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};

export const FeaturesContext = createContext(Features);

export function useFeatures() {
  return useContext(FeaturesContext);
}
```

Los contextos en React se crean con un valor por defecto. En caso de que no exista ningún proveedor que sobrescriba el
valor para el contexto, nuestros componentes recibirán ese valor al acceder a él. En este caso, hemos creado el contexto
utilizando como valor por defecto el propio objeto exportado por `Features`.

```tsx
import { useFeatures } from "../lib/Features";

export function Menu() {
  const features = useFeatures();

  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

Ahora que nuestro componente `Menu` utiliza el nuevo contexto, sólo necesitamos envolver el componente en diferentes
proveedores cuando queramos probar distintos escenarios:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { FeaturesContext } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => false }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => true }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

## `<FeatureFlag />`, un componente para abstraernos por completo

Si utilizamos la API de contextos, podemos ir todavía un paso más allá y abstraernos por completo de la gestión de
funcionalidades disponibles. En este caso, vamos a crear un componente `FeatureFlag` que recibirá la flag sobre la que
queremos trabajar y los nodos que queremos ocultar en caso de no estar disponible:

```tsx
import { ReactNode } from "react";
import { Features, useFeatures } from "../lib/Features";

type FeatureFlagProps = { children: ReactNode; flag: keyof typeof Features };

export function FeatureFlag({ children, flag }: FeatureFlagProps) {
  const features = useFeatures();

  if (features[flag]()) {
    return <>{children}</>;
  }

  return null;
}
```

Al definir la prop de `flag` como `keyof typeof Features` estamos tomando ventaja de la ayuda del compilador de
TypeScript, que nos dirá automáticamente que funcionalidades existen y evitará que utilicemos flags que no se encuentran
en el objeto global de `Features`.

```tsx
import { FeatureFlag } from "./FeatureFlag";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        <FeatureFlag flag="newSettingsPage">
          <li>
            <a href="/settings">Settings</a>
          </li>
        </FeatureFlag>
      </ul>
    </nav>
  );
}
```

Con este último enfoque, nuestras pruebas anteriores utilizando el proveedor del contexto de feature flags seguirán
funcionando (ya que es el mecanismo sobre el que se construye todo) a la vez que tomamos ventaja de un diseño mucho más
idiomático, encapsulando la gestión de feature flags en su propio componente React.


# 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).


# 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)).


# Desacoplando la entrega de software de los sistemas de control de versiones

Como una extensión más de la
[ley de Conway](https://es.wikipedia.org/wiki/Ley_de_Conway), es muy habitual
encontrarse con proyectos donde la estrategia de _branching_ del sistema de
control de versiones está fuertemente relacionada con la estrategia de entrega
de software. Esta relación entre ambos mundos puede parecer conveniente (por
ejemplo: utilizar una rama para representar el código _vivo_ en producción o
_staging_, congelar los cambios que van a desplegarse en una rama `release/*`,
etc.) pero, con el paso del tiempo, puede traer consigo efectos
contraproducentes:

- **Viola el principio de responsabilidad única**. Si algo nos queda claro sobre
  el _Single Reponsability Principle_ es que cada abstracción sólo debe tener
  _una única razón para cambiar_ (en palabras de Robert C. Martin). Si cambios
  en los procesos de entrega de software (flujos de resolución de _hotfixes_,
  nuevos entornos) implican cambios en la estructura de nuestro repositorio (o
  cambios en la manera de interactuar con él), los límites entre ambos contextos
  no están bien establecidos.
- **Todo se vuelve innecesariamente complejo**. Aún con flujos muy populares
  como `git-flow` (y herramientas muy sofisticadas a su alrededor, construidas
  como una capa de abstracción sobre `git`), se _hackea_ el sistema de control
  de versiones para dejar de ser una herramienta de _tracking_ y colaboración
  por un sistema de despliegue y configuración.
- **Resta flexibilidad**. Si es el sistema de control de versiones el encargado
  de determinar qué funcionalidades se van a liberar al final de una iteración,
  se pueden dar situaciones en las que una rama se quede _congelada_ por
  contener funcionalidad defectuosa que inevitablemente contamina al resto de
  cambios de esa misma rama, bloqueando la entrega de nueva funcionalidad.

![Imagen de un repositorio que utiliza git-flow](/static/articles/decoupling-vcs-from-software-delivery/git-flow.jpg "Este repositorio utiliza el sistema de control de versiones como una herramienta de entrega de software para la próxima iteración (aplicando un flujo similar a git-flow)")

Para aliviar los problemas anteriores, una solución pasa por mover la
responsabilidad de decidir qué funcionalidades están disponibles en cada entorno
desde el sistema de control de versiones a la propia base de código. Es decir,
decidir programáticamente si una funcionalidad está habilitada o no en función
de en qué entorno se está ejecutando la aplicación.

Una representación habitual de este principio es a través del uso de
[Feature Flags](https://featureflags.io), que no dejan de ser, conceptualmente,
bloques condicionales que se sitúan en algún punto de nuestra base de código y
deciden si un camino de ejecución debe evaluarse o no.

Con esta estrategia, únicamente necesitaríamos una rama `master` donde fusionar
las _feature branches_ de funcionalidades terminadas y una configuración de
_feature flags_ que defina los entornos en los que estarían disponibles. Por
ejemplo: habilitar la funcionalidad únicamente en entornos de _staging_ para
realizar pruebas de rendimiento, labores de _quality assurance_, etc. La
resolución de hotfixes, se podría realizar igualmente sobre la rama `master`,
pues es esta la que siempre se despliega y define qué funcionalidades estarían
disponibles en cada momento y para cada entorno.

![Imagen de un repositorio con una única rama master y múltiples feature branches](/static/articles/decoupling-vcs-from-software-delivery/with-feature-flags.jpg "En este ejemplo, el repositorio es agnóstico de la capa de entrega de software, que estará gestionada por la propia base de código mediante el uso de feature toggles.")

Siguiendo esta dirección, también se obtendrían beneficios adicionales como, por
ejemplo, poder realizar _merges_ de manera mucho más recurrente (al estar el
entorno de producción siempre protegido a través de _feature flags_). Esto
podría derivar, a su vez, en procesos de _code review_ con un número menor de
cambios y ciclos de _feedback_ más cortos, siempre que lo combinemos con
técnicas como _continuous integration_ y _continuous delivery_.

## Otras lecturas relacionadas

- [Decoupling Deployment from Release - ThoughtWorks' Technology Radar](https://www.thoughtworks.com/radar/techniques/decoupling-deployment-from-release)


# React: MultipleRender

El síntoma más claro de este _code smell_ es la aparición de varios métodos de instancia tipo `render` especializados en
construir una parte de la UI de un componente React. Suele aparecer especialmente en componentes complejos (o de gran
tamaño, como una página) cuando diferentes partes de la interfaz precisan de alguna comprobación o cálculo extra que
afecte a su representación.

```tsx
export class Blog extends React.Component<{ articles: Article[] }> {
  public render() {
    return (
      <>
        {this.renderHeader()}

        {this.renderArticles()}
      </>
    );
  }

  private renderHeader() {
    const {
      articles: { length: numberOfArticles },
    } = this.props;

    if (numberOfArticles === 0) {
      return (
        <header>
          <p>No articles 😯</p>
        </header>
      );
    }

    return (
      <header>
        <p>Yay! {numberOfArticles} articles 🎉</p>
      </header>
    );
  }

  private renderArticles() {
    return this.props.articles.map((article) => {
      return (
        <section>
          <h1>
            <a href={article.url}>{article.title}</a>
          </h1>
        </section>
      );
    });
  }
}
```

En el caso anterior, vemos que la representación de la cabecera de la página varía en función del número de artículos
que se vayan a mostrar. Del mismo modo que la lógica para pintar la colección de artículos está encapsulada en su propio
método de instancia.

Con echar un simple vistazo al método `render`, ya vemos con claridad cuáles son las verdaderas responsabilidades de
nuestra página: definir un _layout_ que muestre una cabecera y una colección de artículos.

¿Es, por tanto, responsabilidad de la página conocer los _internals_ de la cabecera y la lógica necesaria para pintar la
colección de artículos? No. Este componente contiene más de una responsabilidad y no cumple con el
[Principio de Responsabilidad Única](https://en.wikipedia.org/wiki/Single_responsibility_principle).

Para mejorar nuestro diseño, bastaría con definir dos nuevos componentes que encapsulen la lógica necesaria para pintar
ambas partes. Con este enfoque, ganaríamos cierta capacidad para reutilizar esos componentes en otros lugares de nuestra
interfaz (aunque no es condición necesaria para crear un nuevo componente) a la vez que reducimos la complejidad del
componente padre, que no necesita ya llevar consigo toda la lógica de las diferentes partes que la conforman.

Además, si seguís un enfoque de integración y entrega continua, veréis que es mucho más sencillo
[aplicar _feature flags_](/blog/branch-by-abstraction-react) sobre estos pequeños componentes de vuestra interfaz en
lugar de en mitad de componentes grandes y complejos, donde se estarían mezclando responsabilidades y requisitos de
distintas partes de la aplicación.

```tsx
import { Articles } from "./components/Articles";
import { Header } from "./components/Header";

export function Blog(props: { articles: Article[] }) {
  return (
    <>
      <Header {...props} />

      <Articles {...props} />
    </>
  );
}
```

Este _code smell_ está relacionado con otros de propósito general (no relacionados directamente con React) como
[_Large Class_](https://sourcemaking.com/refactoring/smells/large-class) y técnicas de _refactoring_ como
[Extract Class](https://refactoring.guru/extract-class).


# JavaScript: NakedCode

> Código que se escribe y, por tanto se ejecuta, sin estar encapsulado en ningún
> bloque o procedimiento (como por ejemplo una función o una clase).

En JavaScript, sufrimos de una relación de amor-odio con el contexto de
ejecución goblal. Hasta la aparición de los módulos en la especificación de ES6+
la manera más habitual de gestionar dependencias en nuestra aplicación era a
través de la variable global `window`, accesible desde cualquier punto de
nuestro programa.

Con los módulos, llegó una manera de gestionar esas dependencias de manera
explícita y favorecer técnicas como
[tree shaking](https://github.com/rollup/rollup#tree-shaking) para mejorar el
rendimiento de nuestras aplicaciones. Mientras que, a su vez, ganamos también
cierta capacidad para encapsular nuestro código y evitar que se ejecutase en el
contexto global de la aplicación, junto al resto de código de otros ficheros.

Sin embargo, sigue siendo habitual encontrar este tipo de
[code smell](https://martinfowler.com/bliki/CodeSmell.html) gracias a lo
sencillo de codificar directamente en el cuerpo de módulos ECMAScript:

```js
const repository = {};

export function addTodo(todo) {
  if (repository[todo.id]) {
    return;
  }

  repository[todo.id] = todo;
}
```

Aunque escribir código directamente en el cuerpo de un módulo tiene sus casos de
uso, tiene efectos laterales que pueden ser **no** evidentes:

- El código del módulo (sin encapsular) es ejecutado por el intérprete la
  primera vez que se importa, por lo que perdemos la habilidad de controlar
  cuándo evaluar un fragmento de código para, por ejemplo, establecer un
  escenario de ejecución determinado en nuestras pruebas.
- En el ejemplo anterior, la variable `repository` es un objeto _global_ (aunque
  únicamente accesible desde el propio cuerpo del módulo) que dificulta
  enormemente la capacidad de probar el código de manera unitaria, ya que hay
  que gestionar el estado de un variable sobre la que no tenemos acceso.
- Podemos incurrir en problemas de rendimiento (_memory leaks_), al disponer de
  una serie de variables globales sobre las que el recolector de basura no puede
  actuar en caso de no ser necesarias (siempre mantendrán -al menos- una
  referencia).

¿Cómo podríamos mejorar el caso anterior? Envolviendo el cuerpo del módulo en
una función `createRepository` que nos devuelva el control sobre el contexto de
ejecución del repositorio.

```js
export function createRepository(todos = {}) {
  const repository = { ...todos };

  return {
    addTodo(todo) {
      if (repository[todo.id]) {
        return;
      }

      repository[todo.id] = todo;
    },
  };
}
```

A pesar de los problemas anteriores, existen escenarios donde realmente sí
queramos ejecutar código en el cuerpo del módulo para poder beneficiarnos del
hecho de ser una suerte de
[_Singleton_](https://en.wikipedia.org/wiki/Singleton_pattern):

- Fichero `index` donde inicializar dependencias globales de la aplicación.

Cabe recordar que un _code smell_ no significa que algo esté _mal_. Simplemente
se refiere a un patrón que _puede_ (esto es importante) conllevar consigo males
de diseño. En este caso, a no ser que sea plenamente consciente de los efectos
laterales que conlleva, evito utilizar _naked code_ en el cuerpo de mis módulos
JavaScript.


# Branch by Abstraction en Componentes React

En ocasiones, nos vemos en la situación de tener que actualizar varios
componentes de nuestra interfaz de usuario para ajustarlos a nuevas directrices
de diseño. Otras veces, necesitamos reemplazar su implementación para hacer
frente a nuevos requisitos de negocio. Si el número de cambios es lo
suficientemente alto, es posible que no se puedan realizar de manera atómica (o
tengan que ser sincronizados con eventos fuera del control del equipo de
desarrollo como, por ejemplo, la publicación de una nueva imagen de marca) a la
vez que necesitamos continuar entregando valor en forma de nuevas
funcionalidades, corrigiendo defectos o aplicando alguna que otra mejora.

En este artículo vamos a hablar sobre una estrategia que nos permita obtener un
flujo de integración continua evitando, por tanto, mantener los cambios en
nuestros componentes en una rama independiente en el sistema de control de
versiones durante el transcurso de su desarrollo.

¿Cómo lo conseguiremos? Haciendo uso de dos técnicas muy habituales en equipos
que trabajan con prácticas como _continuous integration_ o _continuous
delivery_: [Feature Flags](http://featureflags.io/) (o Feature Toggles si
[leéis a Martin Fowler](https://martinfowler.com/bliki/FeatureToggle.html)) y
[Branch By Abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html).

Ambas estrategias nos permitirán fusionar código de manera regular sobre la rama
principal, aún con funcionalidades parcialmente terminadas, evitando así
mantener ramas en paralelo que podrían estar días (o semanas) sin integrarse con
el trabajo realizado por el resto del equipo.

> Las feature flags son, conceptualmente, bloques condicionales que permiten
> habilitar o deshabilitar una funcionalidad (o un camino de ejecución) en base
> a un conjunto de condiciones (como pueden ser: el entorno de ejecución, el
> perfil del usuario o un porcentaje de tráfico)

Pongamos como ejemplo que, en nuestra aplicación, llevamos ya un tiempo
utilizando `<AwesomeCalendar />` (un componente de terceros) como _widget_ de
calendario. En los puntos donde es necesario mostrar un calendario, importamos
el componente y lo insertamos en el _layout_ de la página.

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <AwesomeCalendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

Debido a una serie de requisitos, tenemos que crear un nuevo componente para
mostrar un calendario que sustituya a `AwesomeCalendar` y le añada un _extra_ de
funcionalidad para dar cabida a nuevas historias de usuario. El desarrollo del
componente se extenderá durante varias semanas.

El primer paso para poder integrar nuestro componente de manera continua es
asegurar que somos capaces de controlar cuándo y cómo se utiliza para poder
aislar a los consumidores de `AwesomeCalendar` de los cambios en el mismo. Para
ello, vamos a empezar creando una nueva _abstracción_ `Calendar` que pasará a
ser utilizada por el resto de componentes y mantendrá la misma interfaz que
ofrecía `AwesomeCalendar`:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

export function Calendar({ date }: { date: Date }) {
  return <AwesomeCalendar date={date} />;
}
```

Como vemos, la manera de consumir este nuevo componente sería muy parecida a la
versión anterior:

```tsx
import React from "react";

import { Calendar } from "../components";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <Calendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

> En este punto, ya podríamos fusionar nuestros cambios con la rama de código
> principal para que el resto de trabajo en curso pueda ir haciendo uso de
> nuestro (no tan) _nuevo_ componente.

A continuación, vamos a crear una implementación muy sencilla de nuestro propio
calendario, que empezará apoyándose en una implementación nativa de `datetime`
pero respetando la interfaz original del componente `AwesomeCalendar`:

```tsx
import React from "react";

export function NewCalendar({ date }: { date: Date }) {
  const value = /* implementation details */;

  return <input type="datetime-local" value={value} />;
}
```

Una vez hemos eliminado la responsabilidad de elegir qué calendario utilizar de
los consumidores del componente, podemos utilizar _feature flags_ para
determinar qué calendario mostrar en cada momento.

En este caso, vamos a permitir que cualquier entorno que **no sea producción**
utilice siempre nuestro propio calendario, con el objetivo de obtener _feedback_
sobre su experiencia de uso a medida que avanzamos en su desarrollo:

```ts
export function isNewCalendarEnabled() {
  return process.env.NODE_ENV !== "production";
}
```

> Este caso, representamos la feature flag con una simple función que comprueba
> el entorno de ejecución actual, pero existen
> [sistemas más sofisticados](https://github.com/Unleash/unleash) para gestionar
> el estado de los _toggles_ en nuestra aplicación.

Ahora, nuestra nueva abstracción `Calendar` (que hace las veces de factoría)
puede hacer uso de esta función para determinar qué componente de calendario
utilizar, manteniendo al resto de consumidores aislados de toda complejidad:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

import { NewCalendar } from "./components";

import { isNewCalendarEnabled } from "../features";

export function Calendar(props: { date: Date }) {
  return isNewCalendarEnabled() ? (
    <NewCalendar {...props} />
  ) : (
    <AwesomeCalendar {...props} />
  );
}
```

A partir de este momento, todas las pantallas de nuestra interfaz de usuario que
necesiten de un calendario, utilizarán la abstracción `Calendar` y será esta
misma abstracción la que se encargará de utilizar la implementación concreta del
calendario que corresponda en función del entorno de ejecución.

Como vemos, aplicar técnicas como _branch by abstraction_ y _feature flags_ nos
permite alcanzar un flujo de integración (y entrega) continua en nuestros
componentes aportándonos beneficios cómo:

- Minimizar la superficie de cambios a fusionar cuando integramos trabajo en
  curso
- Tomar el control sobre cuándo se ejercita un camino de ejecución y poder
  habilitarlo y deshabilitarlo en base a una serie de condiciones
- Dotar a los equipos de negocio de visibilidad sobre el trabajo en curso en
  tareas de larga duración (sin sacrificar ninguna de las premisas anteriores)
