Forem: IagoLast

Testing de SPAs con Vitest Browser Mode: Velocidad de Unit Tests con Confianza E2E

IagoLast — Sun, 21 Dec 2025 20:35:40 +0000

La Revolución del Testing

Kent C. Dodds revolucionó el testing frontend con una idea simple pero poderosa:

"Cuanto más se parezcan tus tests a la forma en que se usa tu software, más confianza pueden darte."

Antes de Testing Library, los tests tenían este aspecto:

// Probando detalles de implementación ❌
const input = wrapper.find(".primary-focus-default-foo");
input.simulate("change", { target: { value: "test@test.com" } });
expect(wrapper.state().email).toBe("test@test.com");

Este enfoque tenía un problema fundamental: estábamos probando cómo funcionaba el código, no lo que experimentaba el usuario. Si renombrábamos una clase CSS o refactorizábamos el estado interno, el test se rompía—incluso si la aplicación seguía funcionando perfectamente.

Testing Library lo cambió todo:

// Probando comportamiento ✅
const input = screen.getByLabelText("Email");
await userEvent.type(input, "test@test.com");
expect(input).toHaveValue("test@test.com");

Ahora nuestros tests se leen como historias de usuario: "buscar el input de email, escribir un email, verificar que aparece". Si cambia la clase CSS, el test sigue pasando. Si cambiamos el estado de React por una librería de formularios, el test sigue pasando. Estamos probando comportamiento, no implementación.

La Era de jsdom: Velocidad a un Coste

Los tests con Testing Library son rápidos—milisegundos, no segundos. Esta velocidad viene de jsdom, una implementación de JavaScript del DOM que se ejecuta en Node.js.

En lugar de lanzar un navegador real, jsdom simula uno en memoria. Nuestros tests se ejecutan al instante porque no hay arranque del navegador, no hay motor de renderizado, no hay pila de red real.

Pero jsdom es una simulación. No implementa todo:

No hay renderizado real de CSS ni cálculos de layout
No hay peticiones de red reales
Diferencias sutiles en el manejo de eventos
APIs web que faltan

Para la mayoría de tests, esto no importa. Pero de vez en cuando, un test pasa en jsdom y falla en un navegador real. O peor: un test pasa en todas partes, pero la funcionalidad está rota en producción.

El Problema de los Efectos Secundarios: MSW y server-stubs

Incluso con una simulación perfecta del DOM, nuestras aplicaciones no existen aisladas. Hacen peticiones HTTP. Leen cookies. Interactúan con servidores.

Nuestros tests necesitan manejar estos efectos secundarios. La comunidad se decantó por MSW (Mock Service Worker) como solución estándar. MSW intercepta las peticiones HTTP a nivel de red—nuestra aplicación no sabe que está siendo testeada.

import { http, HttpResponse } from "msw";
import { setupServer } from "msw/browser";

const server = setupServer(
  http.get("/api/users", () => {
    return HttpResponse.json([
      { id: 1, name: "John" },
      { id: 2, name: "Jane" },
    ]);
  })
);

MSW es potente, pero configurar los handlers puede volverse verboso. Por eso construimos @frontend-testing/server-stubs—una capa fina sobre MSW que simplifica el stubbing a una sola línea:

import { stubJsonResponse } from "@frontend-testing/server-stubs";

const { spy } = stubJsonResponse({
  path: "*/api/users",
  method: "GET",
  response: [{ id: 1, name: "John" }],
});

// Después de la petición:
expect(spy).toHaveBeenCalledTimes(1);

Sin boilerplate de handlers. Spies de peticiones integrados. Respuestas secuenciales para lógica de reintentos. Todos los patrones comunes, simplificados.

2025: Vitest Browser Mode lo Cambia Todo

Luego llegó Vitest 2.0 con Browser Mode, y el panorama cambió.

Browser Mode ejecuta tus tests en un navegador real—Chromium, Firefox o WebKit—mientras mantiene la velocidad de Vitest. No más jsdom. No más simulaciones. DOM real, eventos reales, APIs reales del navegador.

// vitest.config.ts
import { playwright } from "@vitest/browser-playwright";
import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      provider: playwright(),
      instances: [{ browser: "chromium" }],
    },
  },
});

Tus tests se ejecutan en milisegundos—igual que con jsdom—pero en un navegador real. La brecha de confianza se cierra.

Mi Enfoque: Casi E2E, a Velocidad de Unit Test

Con estas piezas en su lugar, propongo una estrategia de testing que te da la confianza de E2E a velocidad de unit test:

Usar Vitest Browser Mode — Navegador real, confianza real
Renderizar la aplicación completa — No componentes aislados, la app real
Navegar a la ruta bajo prueba — Usando @frontend-testing/vitest-browser-navigate
Hacer stub de respuestas del servidor — Usando server-stubs sobre MSW
Opcionalmente sembrar estado — Cookies, localStorage, tokens de autenticación

Todo lo demás es real. Routing real. Componentes reales. Interacciones de usuario reales.

El Problema de la Navegación

Hay un detalle: en Browser Mode, tu app se renderiza dentro de un iframe. No puedes simplemente cambiar window.location—necesitas simular la navegación de una SPA.

Por eso construimos @frontend-testing/vitest-browser-navigate:

npm install -D @frontend-testing/vitest-browser-navigate

// vitest.config.ts
import { navigate } from "@frontend-testing/vitest-browser-navigate";

export default defineConfig({
  test: {
    browser: {
      commands: { navigate },
    },
  },
});

Ahora puedes navegar como un usuario:

import { commands } from "vitest/browser";

await commands.navigate("/dashboard");

Bajo el capó, llama a history.pushState() y dispara un evento popstate. Tu router—React Router, Vue Router, el que uses—reacciona exactamente igual que con navegación real.

Ejemplo Completo: Testeando un Flujo de Login

// login-page.spec.tsx
import "@frontend-testing/vitest-browser-navigate";
import App from "@/App";
import { stubJsonResponse } from "@frontend-testing/server-stubs";
import { screen, waitFor } from "@testing-library/react";
import { describe, expect, test } from "vitest";
import { render } from "vitest-browser-react";
import { commands, userEvent } from "vitest/browser";

describe("LoginPage", () => {
  test("should login and redirect to dashboard", async () => {
    // 1. Hacer stub de la respuesta del servidor
    const { spy } = stubJsonResponse({
      path: "*/auth/login",
      method: "POST",
      response: { token: "mock-token", user: { id: 1 } },
    });

    // 2. Navegar a la página de login
    await commands.navigate("/login");

    // 3. Renderizar la aplicación COMPLETA
    await render(<App />);

    // 4. Interactuar como un usuario real
    await userEvent.type(
      screen.getByLabelText("Email"),
      "test@test.com"
    );
    await userEvent.type(
      screen.getByLabelText("Password"),
      "password123"
    );
    await userEvent.click(
      screen.getByRole("button", { name: "Login" })
    );

    // 5. Verificar que la petición se hizo correctamente
    expect(spy).toHaveBeenCalledTimes(1);
    expect(spy.mock.calls[0][0].body).toEqual({
      email: "test@test.com",
      password: "password123",
    });

    // 6. Verificar que la navegación ocurrió
    await waitFor(() => {
      expect(window.location.pathname).toBe("/dashboard");
    });
  });
});

Fíjate en lo que estamos probando:

✅ Renderizado en navegador real
✅ Routing completo de la aplicación
✅ Interacciones de usuario reales
✅ Verificación de peticiones HTTP
✅ Resultados de navegación

El único mock es la respuesta del servidor. Todo lo demás es la aplicación real.

Por Qué Funciona Este Enfoque

Este enfoque funciona porque combina lo mejor de ambos mundos: la velocidad de los unit tests con la confianza de los tests E2E. Mis tests se ejecutan en un navegador real, así que si pasan, la funcionalidad realmente funciona—no más sorpresas de "funciona en jsdom". Los tests se completan en milisegundos, permitiéndome ejecutar cientos en segundos y mantener mi flujo de desarrollo ágil. Pruebo comportamiento, no implementación, lo que significa que los refactors no rompen tests y los cambios de CSS no rompen tests—solo los cambios de funcionalidad real lo hacen. Y es simple: un patrón para todo. Navegar, interactuar, verificar. Sin infraestructura compleja de E2E, sin servidores separados de Cypress, sin mantener dos suites de tests diferentes.

Empezando

Configurar este stack de testing lleva unos 10 minutos. Aquí tienes una guía paso a paso.

1. Instalar Dependencias

Primero, instala Vitest con soporte para browser mode y nuestras librerías auxiliares:

npm install -D vitest @vitest/browser playwright
npm install -D @frontend-testing/vitest-browser-navigate
npm install -D @frontend-testing/server-stubs msw

Si estás usando React, también querrás las utilidades de render compatibles con el navegador:

npm install -D vitest-browser-react @testing-library/react

2. Configurar Vitest

Crea o actualiza tu vitest.config.ts para habilitar browser mode y registrar el comando navigate:

// vitest.config.ts
import { playwright } from "@vitest/browser-playwright";
import { navigate } from "@frontend-testing/vitest-browser-navigate";
import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      provider: playwright(),
      instances: [{ browser: "chromium" }],
      commands: { navigate },
    },
    setupFiles: ["./test/setup.ts"],
  },
});

3. Configurar MSW y server-stubs

Crea un archivo de setup de tests que inicialice MSW. El serverManager de server-stubs desacopla el servidor MSW de tus archivos de test, así que lo configuras una vez y usas stubs en cualquier lugar:

// test/setup.ts
import { setupWorker } from "msw/browser";
import { serverManager } from "@frontend-testing/server-stubs";
import { beforeAll, afterEach, afterAll } from "vitest";

const server = setupWorker();
serverManager.setDefaultServerLoader(() => server);

beforeAll(() => server.start({ onUnhandledRequest: "warn" }));
afterEach(() => server.resetHandlers());
afterAll(() => server.stop());

La opción onUnhandledRequest: "warn" es útil durante el desarrollo—registra una advertencia cuando tu app hace una petición que no está stubbeada, ayudándote a detectar mocks faltantes.

4. Escribir Tu Primer Test

Ahora estás listo para escribir tests. Crea un archivo spec e importa todo lo que necesites:

// src/pages/home.spec.tsx
import { stubJsonResponse } from "@frontend-testing/server-stubs";
import { screen } from "@testing-library/react";
import { describe, expect, test } from "vitest";
import { render } from "vitest-browser-react";
import { commands, userEvent } from "vitest/browser";
import App from "./App";

describe("HomePage", () => {
  test("displays user data after loading", async () => {
    // Hacer stub de la API
    stubJsonResponse({
      path: "*/api/user",
      response: { name: "John Doe", email: "john@example.com" },
    });

    // Navegar y renderizar
    await commands.navigate("/");
    await render(<App />);

    // Verificar
    await expect.element(screen.getByText("John Doe")).toBeVisible();
  });
});

5. Ejecutar Tus Tests

npx vitest

Vitest lanzará un navegador, ejecutará tus tests y mostrará los resultados en la terminal. Los tests se ejecutan en modo watch por defecto, re-ejecutándose cuando guardas cambios.

Para entornos de CI, usa:

npx vitest run

Eso es todo. Estás testeando en un navegador real, a velocidad de unit test.

¿Preguntas? Abre un issue en GitHub.

Y si, este post esta escrito por IA, pero revisado por mi :)

¿Qué podemos hacer con #laligagate?

IagoLast — Wed, 16 Apr 2025 13:58:19 +0000

Ya llevaba tiempo viendo en redes que muchos usuarios se quejaban de que sus webs estaban siendo bloqueadas por LaLiga. Hasta que este fin de semana me tocó a mí.

Soy una persona honrada y muy trabajadora. Trabajo como un idiota, muchas horas al día. Pago una barbaridad de impuestos, cumplo todas las normativas absurdas que se me imponen, y me esfuerzo por hacer las cosas bien. Me dejo la piel para que mis webs funcionen, tengan visitas, generen ingresos, y poder ganarme la vida dignamente con software. ¿Y con qué me encuentro? Con que, de un día para otro, puede aparecer un mensaje en mi web diciendo: "esta página alberga contenido pirata y ha sido bloqueada". Aunque no tenga nada que ver. Aunque no haya hecho absolutamente nada malo.

El problema

En España, como en muchos otros países, hay personas que consumen fútbol de forma ilegal a través de páginas web no autorizadas. Estas webs suelen utilizar servicios de infraestructura completamente legítimos, los mismos que emplean miles de negocios online para operar. El problema no está en el proveedor, sino en el uso que algunos hacen de él. Para entenderlo con una analogía sencilla: una banda criminal puede alquilar un piso para llevar a cabo actividades delictivas. El piso, el edificio, e incluso la compañía eléctrica que les da servicio, no tienen ninguna responsabilidad directa. El problema es lo que ocurre dentro de una unidad concreta.

La situación, desde el punto de vista técnico, es compleja. Internet funciona sobre capas de protocolos que, por diseño, no permiten identificar fácilmente a qué web pertenece una dirección IP determinada. Además, las nuevas tecnologías que refuerzan la privacidad de los usuarios —como el cifrado del tráfico o el uso compartido de infraestructuras— dificultan aún más esa identificación. Esto provoca que, en la práctica, sea muy difícil aplicar un bloqueo quirúrgico. Es como si quisieras cerrar solo los pisos de tu ciudad donde se cometen delitos, pero no tuvieras forma de saber con precisión en cuáles se está produciendo la actividad ilegal.

La demanda

LaLiga lleva tiempo impulsando medidas judiciales agresivas contra plataformas que considera facilitadoras del acceso ilegal a sus contenidos. Hace apenas unos meses consiguió que se bloqueara Telegram en España. La medida se revirtió en pocas horas, pero fue un aviso: no iban a detenerse. Esta vez no han ido a por una aplicación, sino contra la infraestructura misma de internet.

En diciembre de 2024, LaLiga y Telefónica Audiovisual Digital (Movistar+) interpusieron una demanda contra los principales operadores de internet en España. El truco está en que Telefónica, a través de otras filiales, aparecía también como parte demandada. Es decir, era demandante y demandada al mismo tiempo.

Y, curiosamente, todas las partes demandadas se allanaron. Es decir, aceptaron sin reservas lo que LaLiga pedía. No hubo oposición. No hubo debate técnico. No se evaluaron alternativas. El juzgado dictó resolución de forma inmediata y sin escuchar a terceros potencialmente afectados.

Para que nos entendamos: La conclusión de todo esto es que como no sabemos en qué pisos se están cometiendo delitos, optamos por bombardear bloques de viviendas enteros, por si acaso...

La sentencia

https://www.redes-sociales.com/wp-content/uploads/2025/04/sentencia-bloqueos-ips-laliga-SJM_B_309_2024.pdf

La resolución dictada por el Juzgado Mercantil de Barcelona el 18 de diciembre de 2024 se basa en los artículos 138 y 139.1.h) del Texto Refundido de la Ley de Propiedad Intelectual.

El artículo 138 establece que:

“Tanto las medidas de cesación específicas contempladas en el artículo 139.1.h) como las medidas cautelares previstas en el artículo 141.6 podrán también solicitarse, cuando sean apropiadas, contra los intermediarios a cuyos servicios recurra un tercero para infringir derechos de propiedad intelectual reconocidos en esta ley, aunque los actos de dichos intermediarios no constituyan en sí mismos una infracción, sin perjuicio de lo dispuesto en la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico. Dichas medidas habrán de ser objetivas, proporcionadas y no discriminatorias.”

Y el artículo 139.1.h), por su parte, dice:

“La suspensión de los servicios prestados por intermediarios a terceros que se valgan de ellos para infringir derechos de propiedad intelectual, sin perjuicio de lo dispuesto en la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico.”

La ley permite actuar contra intermediarios, incluso si estos no son infractores directos, pero impone una condición explícita: que las medidas adoptadas sean proporcionadas, objetivas y no discriminatorias. Además, ambas remiten a la LSSI como límite legal que debe respetarse en todo caso.

En esta sentencia, el juzgado acepta por completo los informes técnicos presentados por LaLiga y Telefónica, en los que se afirma que tecnologías como ECH y Apple Relay impiden aplicar bloqueos selectivos a nivel de dominio. A partir de ahí, se concluye que el único medio efectivo es el bloqueo de direcciones IP completas.

En ningún momento se plantea si existen alternativas menos lesivas. Tampoco se solicita una verificación técnica externa. Ni se valora cuántas webs o servicios legales pueden verse afectados por esa decisión.

En el fundamento segundo se afirma expresamente:

“Sin que dicho allanamiento sea contrario a la ley, al orden público ni perjudica a terceros.”

Esa afirmación no va acompañada de ninguna evaluación. Se asume que no hay perjuicio, sin contrastarlo, sin pedir datos ni tener en cuenta la naturaleza compartida de muchas infraestructuras.

Además, se autoriza a LaLiga y a Telefónica a actualizar dinámicamente las IP bloqueadas enviando nuevas listas cada semana —incluso en fines de semana y festivos— sin intervención judicial previa. El control de la ejecución queda así delegado en la parte actora, sin supervisión externa ni mecanismo de revisión.

Lo que se permite en esta sentencia no es una acción puntual ni limitada. Es un sistema automatizado de bloqueos, sostenido en el tiempo, y gestionado por los propios interesados. Una medida que debería ser excepcional se convierte en procedimiento ordinario.

La proporcionalidad no se analiza. El posible perjuicio a terceros no se investiga. La neutralidad de la red no se menciona. Y los principios de la LSSI —como la mínima intervención o el respeto a los servicios legales— quedan, en la práctica, sin garantía efectiva.

Qué podemos hacer!?

Aunque la sentencia ya ha sido dictada y los bloqueos están en marcha, no significa que tengamos que aceptarlo como algo inevitable. Hay caminos posibles, aunque no son sencillos, y el más urgente es dejar de actuar cada uno por su cuenta. Necesitamos coordinarnos, organizarnos, y hacernos oír.

Desde el punto de vista jurídico, algunas empresas y profesionales podrían explorar la vía de actuar como terceros perjudicados. Es una opción legalmente prevista, pero compleja. Requiere demostrar que se ha producido un daño directo —como la interrupción de un servicio legítimo por el bloqueo de una IP compartida—, que ese daño vulnera derechos fundamentales como la libertad de expresión, la libertad de empresa o la tutela judicial efectiva, y que además no se tuvo oportunidad de participar en el proceso judicial. Es una vía exigente, incierta, y que requerirá asesoramiento legal especializado si se decide intentarla.

También es posible cuestionar cómo se está ejecutando esta sentencia. Aunque el fallo hable de bloquear contenidos ilegales sin afectar a terceros, la realidad es que se están cortando rangos completos de IPs, sin revisión previa, sin transparencia, y afectando a webs perfectamente legales. Si se puede demostrar el perjuicio, se podrían exigir explicaciones o incluso una exclusión del bloqueo, pero tampoco es un camino fácil ni rápido.

Por eso, más allá de lo judicial, necesitamos actuar en el plano administrativo y político. Deberíamos presentar reclamaciones ante la CNMC, que tiene la obligación de supervisar a los operadores y velar por la neutralidad de la red. También ante el Ministerio de Asuntos Económicos y Transformación Digital (y que por una vez sirva para algo) que debe proteger los derechos digitales de ciudadanos y empresas.

Por último, deberíamos intentar escalar el tema a Europa, donde todo este asunto podría ir en contra del reglamento de acceso a internet.

Pero para que algo de esto funcione, lo primero es organizarnos y sobre todo hacerlo visible. Si no basta con decirlo a los medios o a los organismos reguladores, habrá que decirlo también a los patrocinadores de LaLiga.

Esto no va de fútbol ni de propiedad intelectual.

Va de cómo se regula internet y de como poco a poco con la excusa de "la seguridad" o del orden vamos perdiendo libertad.

Next.js 14: No hemos aprendido NADA 😡

IagoLast — Mon, 30 Oct 2023 07:55:47 +0000

Hace ya algún tiempo que Next.js está en el foco del desarrollo frontend. Es el framework de moda: rápido, moderno, fantasticoso (fantástico y maravilloso).

Como ocurre con cada nueva tecnología, miles de desarrolladores aspiran a ser early adopters y dedican una fortuna para reemplazar tecnologías obsoletas con las más relucientes. Next.js no es una excepción.

Quiero aclarar que ni soy un experto en Next.js ni soy un detractor. De hecho, me gusta Next y creo que ofrece ideas y avances muy valiosos para la comunidad. Sin embargo, he observado que están cometiendo un error, en mi opinión, GRAVE. Esta semana, tras la conferencia donde se presentó next/learn, decidí que escribiría un artículo al respecto.

El error es tan fundamental que se puede resumir en una frase:

El ecosistema de Next.js relega el testing.

A pesar de enfatizar constantemente las ventajas de rendimiento, la rapidez del compilador, la eficiencia del app router y la revolucionaria naturaleza de los server-side-components, en toda la documentación ni se menciona el TESTING.

En versiones anteriores al app router (pages), al menos contaban con una sección sobre testing en el apartado de "optimizaciones". Sin embargo, esta sección ha desaparecido en la documentación actual.

Es sorprendente, pero parece que en pleno 2023 debemos recordar nuevamente la importancia del testing automático. Afortunadamente, en Vercel ya lo saben, pues el primer punto destacado de Next14 es que cuentan con 5000 tests en su base de código.

Aún así, por razones desconocidas, continúan omitiendo casi por completo toda referencia a testing. Cómo si sus clientes no necesitasen hacer pruebas.

Yo tengo una opinión bastante radical, creo que los tutoriales y ejemplos deberían seguir la metodología TDD y cada muestra de código debería incluir un test asociado. Aunque se que esto es una utopía que únicamente existe en mi cabeza, creo que al menos sería positivo que desde Next se promoviesen un MÍNIMO estas buenas prácticas y al menos preparasen el terreno para que la comunidad interesada en testing pueda investigar y generar contenido.

Al iniciar una app desde cero, no te pregunta por el framework de unit testing que utilizarás ni incluye un script de test predeterminado.

Ni siquiera incluye un script de "test":

{
"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
}

No me doy por vencido. Intentaré configurar Jest siguiendo los ejemplos proporcionados en la documentación anterior.

El tutorial es bastante directo. Instalo las dependencias:

npm install --save-dev jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom

Luego, creo el archivo jest.config.mjs:

import nextJest from 'next/jest.js'

const createJestConfig = nextJest({
  // Provide the path to your Next.js app to load next.config.js and .env files in your test environment
  dir: './',
})

// Add any custom config to be passed to Jest
/** @type {import('jest').Config} */
const config = {
  // Add more setup options before each test is run
  // setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],

  testEnvironment: 'jest-environment-jsdom',
}

// createJestConfig is exported this way to ensure that next/jest can load the Next.js config which is async
export default createJestConfig(config)

Y finalmente realizo un test de prueba. Todo parece funcionar.

Sin embargo, ¿qué ocurre con los server-side components asíncronos?


async function getData(): Promise<string> {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("World");
    }, 1000);
  });
}

export default async function Home() {
  const data = await getData();
  return <h1>Hello {data}</h1>;
}

Este componente funciona perfectamente en Next, pero al intentar ejecutar los tests nuevamente…

Es evidente: no es posible realizar tests unitarios de páginas SSR. Actualmente, la única opción que conozco es utilizar tests E2E con Playwright o Cypress.

Pero si queremos probar cosas tan "sencillas" (o al menos comunes) cómo layouts, rutas complejas y otros aspectos que anteriormente eran fácilmente testables con Jest + Testing Library estamos totalmente abandonados.

Conclusión

Hoy, resulta complejo (si no imposible) desarrollar una aplicación en Next.js con tests unitarios. Los tests son herramientas esenciales para garantizar la calidad del software y la eficiencia en el desarrollo.

Lamentablemente, el framework que promete liderar el desarrollo frontend en los próximos años parece desestimar la importancia del testing.

Me preocupa que, si ya es difícil convencer a los desarrolladores de realizar pruebas, si el framework no ayuda será una batalla perdida.

Espero que alguien del equipo de Next (preferentemente hispanohablante ;) ) lea esto y tome acciones, pues insisto: es una tecnología impresionante.

UTC considered harmful

IagoLast — Wed, 26 Jul 2023 15:57:09 +0000

Decidí fundar TimeTime.in porque, al contrario de lo que mucha gente piensa, trabajar con fechas sigue siendo terriblemente complicado para un desarrollador. (No es casualidad que el Datepicker habitualmente sea de pago en muchas librerías de UI).

Hace no mucho tiempo, estaba en Twitter y me encontré un post de Ben Nadel, un desarrollador nada sospechoso de ser junior, contando un problema que había tenido manejando fechas y enlazando a un post explicando su solución.

Para mi sorpresa, su solución no es totalmente correcta, así que me he animado a escribir este post para evitar que más desarrolladores caigan en el mismo error.

¡Lo primero de todo!

Como no quiero hacer este post muy largo, voy a empezar introduciendo los conceptos mínimos necesarios para entenderlo.

Tiempo Civil vs UTC

Como mucha gente sabe, en Internet la mayoría de las fechas se representan usando tiempo UTC (en realidad se utiliza tiempo UNIX, que no es UTC y tiene bastantes problemas si queremos conseguir algo de seriedad, pero eso es material para otro post). Simplificando, podemos decir que el tiempo UTC representa el número de segundos a partir de un tiempo de referencia.

Como no es práctico hablar en segundos constantemente, los humanos utilizamos un sistema diferente para representar fechas, llamado tiempo civil. Los humanos no decimos “he nacido en 89891283”, decimos “he nacido el 4 de julio de 1992 en Pontevedra, España”.

Si hay algo importante en este texto, es que esta diferencia esté clara. Los humanos hablamos en tiempo civil y las máquinas en tiempo estandarizado, y si queremos tener un sistema informático que funcione, tenemos que ser capaces de transformar un formato en el otro de forma efectiva.

Husos horarios, zonas horarias y GMT offset

Simplificando, en 1884 se celebró la conferencia del meridiano, donde se acordó dividir la tierra en 24 husos horarios separados por 15º entre sí.

Los husos horarios son diferentes a las zonas horarias. Una zona horaria es una región geográfica que comparte una misma hora oficial. Es muy importante entender que una zona horaria es un concepto de tiempo civil cuyas normas pueden cambiar arbitrariamente.

Por último, hay que hablar del offset GMT. El GMT offset es la diferencia en horas y minutos entre la hora de referencia (GMT) y una hora concreta.

(Muchas veces la gente habla de “offset UTC”, aunque cabe recordar que GMT es una zona horaria mientras que UTC es un estándar de tiempo.)

ISO 8601

Es una normativa estándar que especifica la notación para representar, entre otros, fechas y horas. En esta normativa se indica que este es el formato para representar una fecha con horas, minutos, segundos y milisegundos:

yyyy-mm-ddThh:mm:ss.mmm

Además, este formato contempla que se pueda indicar la hora utilizando la zona horaria local, añadiendo cuánto desfase (offset) hay respecto a GMT. Si el desfase es 0, se añade una Z al final.

yyyy-mm-ddThh:mm:ss.mmmZ

Es decir, el mismo instante de tiempo (UTC) en España se llamará “26/07/2023 15:51:19 de España” y en Portugal, que está en una zona horaria anterior, se llamará “26/07/2023 14:51:19 de Portugal”.

ISO	GMT	UTC (ms)	Tiempo civil
2023-07-26T13:51:19.724Z	2023-07-26T13:51:19.724Z	1690379479724	26/07/2023 15:51:19 de España
2023-07-26T14:51:19.724-01:00	2023-07-26T13:51:19.724Z	1690379479724	26/07/2023 14:51:19 de Portugal

Developers

Ahora que hemos visto todo esto, ¿qué implicaciones tiene para nosotros como desarrolladores?

Nivel 0: Timestamps

Mucha gente utiliza timestamps para representar fechas. Como hemos visto, los timestamps son un concepto de tiempo absoluto que no tiene en cuenta ni el offset ni la zona horaria.

Este es el problema que tiene Ben y que explica en su blog. Tiene una aplicación de deportes en la que guarda datos de entrenamientos. Tiene una funcionalidad de “racha de entrenos” donde básicamente indica qué días el usuario ha entrenado.

En un primer momento, guardaba los entrenamientos como timestamps, el problema es que un usuario en la zona este de EEUU, se encuentra en offset GMT-4, esto quiere decir que si entrena a las 5 de la mañana y a las 10 de la noche ha entrenado dos días diferentes en la zona horaria GMT, pero el mismo día en GMT-4.

Por ejemplos como este, guardar timestamps es muchas veces insuficiente si queremos conservar la semántica de las fechas.

Nivel 1: GMT offset

Una solución habitual es almacenar las fechas incluyendo el offset GMT. De esta forma, al saber el offset de un usuario, sabemos si clasificar los entrenamientos en diferentes días o no. Sin embargo, esta aproximación tiene un problema: Asumir que las zonas horarias son estáticas.

Como hemos visto previamente, una zona horaria es diferente a un offset GMT. El ejemplo típico que todos conocemos es el cambio entre el horario de verano y el horario de invierno. Además, las propias zonas horarias pueden cambiar debido a decisiones políticas. Sin ir más lejos, España cambió de huso horario en 1940.

Nivel 2: ISO + Zona Horaria

Sin entrar en muchos detalles aburridos, puedo decir sin miedo a equivocarme que la forma correcta de almacenar y transmitir fechas suele ser utilizando formato ISO + Zona Horaria.

Pongamos un ejemplo. Supongamos que tengo una aplicación que permite reservar citas médicas. Como en España la sanidad no va todo lo bien que debería, me dan cita para dentro de meses.

Tu cita ha sido programada para el Sábado 20 de julio de 2024 a las 09:00 de la mañana, hora española peninsular.

Esta fecha y hora, están expresadas en tiempo civil.

Imaginemos que guardamos la fecha en mi base de datos almacenando fecha y GMT offset en formato ISO.

2024-07-20T09:00:00.000+02:00

Esta fecha se corresponde con un instante UTC determinado:

1721458800000

Y a su vez se corresponde con esta fecha en GMT:

Sat, 20 Jul 2024 07:00:00 GMT

Ahora imaginemos que entre medias, algunos países de Europa, incluido España, deciden eliminar el horario de verano. Para cuando llegue el día en nuestra base de datos, seguimos teniendo:

2024-07-20T09:00:00.000+02:00 (1721458800000 UTC)

Que transformado al hipotético horario civil español después del cambio de hora será:

El Sábado 20 de julio de 2024 a las 08:00 de la mañana, hora española peninsular.

Sin embargo, ¿es esto lo que queremos? ¿Queremos persistir el instante UTC original al que se correspondía la fecha civil? ¿O queremos conservar la hora inicial a la que el paciente pidió la cita médica?

En mi opinión, cuando una persona pide cita para el médico a las 9 de la mañana, no le importa el tiempo UTC o GMT ni los cambios horarios que se realicen en su país entre medias. Le importa que su cita sea su hora civil local.

En mi caso cuando digo “Sábado 20 de julio de 2024 a las 09:00 de la mañana, hora española peninsular”, no me importa lo que pueda pasar entre medias, ¡quiero mi cita a las 09:00 de la mañana!

Conclusiones

En este texto, sólo hemos tocado la superficie de todas las implicaciones y trampas que te puedes encontrar manejando fechas por poner algunas:

Hasta 1908 Rusia utilizaba el calendario juliano, causando entre otras cosas, que llegasen 12 días tarde a los Juegos Olímpicos de ese año.
Existió el 30 de febrero.
El tiempo UNIX, (utilizado en las fechas javascript) no es exactamente el tiempo UTC.

De momento siempre que manejes fechas te recomiendo tener este texto en cuenta y si es necesario persistir la zona horaria junto a la fecha para conservar tanta información como sea posible.

UTC considered harmful

IagoLast — Wed, 26 Jul 2023 15:56:58 +0000

I decided to launch TimeTime.in because, contrary to popular belief, working with dates is still terribly complicated for developers. (It's no coincidence that the Datepicker is often paid in many UI libraries).

Not long ago, I was on Twitter and came across a post by Ben Nadel, a developer not suspected of being a junior, discussing a problem he faced with dates and linking to a post explaining his solution.

To my surprise, his solution isn't entirely correct, so I was inspired to write this post to prevent more developers from making the same mistake.

First things first!

Not wanting to make this post too long, I'll start by introducing the basic concepts required to understand it.

Civil Time vs UTC

As many people know, on the Internet most dates are represented using UTC time (actually UNIX time is used, which isn't UTC and has significant issues if we want to be serious, but that's material for another post). Simplifying, we can say that UTC time represents the number of seconds from a reference time.

Practically, instead of continuously talking in seconds, humans use a different system to represent dates called civil time. We don't say “I was born at 89891283”, we say “I was born on July 4, 1992, in Pontevedra, Spain”.

The crucial point here is to understand this difference. Humans speak in civil time and machines in standardized time, and if we want a functioning computer system, we need to effectively transform one format into the other.

Time Zones, Area Zones, and GMT Offset

In simple terms, the 1884 meridian conference was held where it was agreed to divide the earth into 24 time zones, each separated by 15º.

Time zones are different from area zones. An area zone is a geographical region that shares the same official time. It's essential to understand that an area zone is a civil time concept whose rules can change arbitrarily.

Lastly, we should discuss the GMT offset. The GMT offset is the difference in hours and minutes between the reference time (GMT) and a specific time.

(People often talk about the “UTC offset”, even though it's important to remember that GMT is a time zone, whereas UTC is a time standard.)

ISO 8601

It's a standard regulation specifying the notation to represent dates, times, and more. This standard indicates that the format for representing a date with hours, minutes, seconds, and milliseconds is:

yyyy-mm-ddThh:mm:ss.mmm

Furthermore, this format allows specifying time using the local time zone, adding how much offset there is from GMT. If the offset is 0, a Z is added at the end.

yyyy-mm-ddThh:mm:ss.mmmZ

Meaning, the same moment in time (UTC) in Spain will be called "26/07/2023 15:51:19 in Spain" and in Portugal, which is in a prior time zone, it'll be called "26/07/2023 14:51:19 in Portugal".

ISO	GMT	UTC (ms)	Civil Time
2023-07-26T13:51:19.724Z	2023-07-26T13:51:19.724Z	1690379479724	26/07/2023 15:51:19 in Spain
2023-07-26T14:51:19.724-01:00	2023-07-26T13:51:19.724Z	1690379479724	26/07/2023 14:51:19 in Portugal

Developers

Now that we've covered this, what implications does it have for us as developers?

Level 0: Timestamps

Many people use timestamps to represent dates. As we've seen, timestamps are an absolute time concept that doesn't account for the offset or time zone.

This is the problem Ben faced and explained on his blog. He has a sports app where he saves training data. It has a “training streak” feature which essentially shows which days the user trained.

Initially, he saved workouts as timestamps. The problem is for a user in the Eastern US, which is in GMT-4 offset. This means if they train at 5 in the morning and 10 at night, they've trained on two different days in GMT time, but the same day in GMT-4.

Examples like this show that saving timestamps is often inadequate if we want to preserve date semantics.

Level 1: GMT Offset

A common solution is to store dates, including the GMT offset. This way, knowing a user's offset, we know whether to classify workouts on different days or not. However, this approach has one problem: Assuming that time zones are static.

As previously discussed, a time zone differs from a GMT offset. The classic example we all know is the switch between daylight saving time and standard time. Moreover, time zones themselves can change due to political decisions. For instance, Spain changed its time zone in 1940.

Level 2: ISO + Time Zone

Without delving into many tedious details, I can confidently say that the correct way to store and transmit dates is usually by using the ISO format + Time Zone.

Let's take an example. Suppose I have an app that allows booking medical appointments. Since healthcare in Spain isn't as good as it should be, they schedule my appointment for months later.

Your appointment is scheduled for Saturday, July 20, 2024, at 09:00 AM, Spanish mainland time.

This date and time are expressed in civil time.

Imagine that we save this date in my database, storing the date and GMT offset in ISO format.

2024-07-20T09:00:00.000+02:00

This date corresponds to a certain UTC moment:

1721458800000

Which in turn corresponds to this GMT date:

Sat, 20 Jul 2024 07:00:00 GMT

Now let's imagine that in the meantime, some countries in Europe, including Spain, decide to abolish daylight saving time. By the time the day comes in our database, we still have:

2024-07-20T09:00:00.000+02:00 (1721458800000 UTC)

Transformed to the hypothetical Spanish civil time after the time change will be:

Saturday, July 20, 2024, at 08:00 in the morning, Peninsular Spanish time.

However, is this what we want? Do we want to persist the original UTC moment to which the civil date corresponded? Or do we want to preserve the initial time when the patient requested the medical appointment?

In my opinion, when a person schedules a medical appointment for 9 in the morning, they don't care about UTC or GMT or any daylight saving time changes that occur in their country in the meantime. They care about their appointment being at their local civil time.

In my case, when I say "Saturday, July 20, 2024, at 09:00 in the morning, Peninsular Spanish time," I don't care about anything that happens in between—I want my appointment at 09:00 in the morning!

Conclusions

In this text, we have only scratched the surface of all the implications and pitfalls you can encounter when dealing with dates, just to name a few:

Until 1908, Russia used the Julian calendar, causing them to arrive 12 days late to the Olympics that year.
There was a February 30th.
The UNIX time (used in JavaScript dates) is not exactly the UTC time.

For now, whenever you handle dates, I recommend keeping this text in mind, and if necessary, persist the time zone along with the date to preserve as much information as possible.

D5, La metodología que me funciona.

IagoLast — Thu, 13 Apr 2023 18:54:52 +0000

Agile, kanban, waterfall, proces unficiado… son decenas las metodologías que se han propuesto para desarrollar software a lo largo de la historia. Tras más de una década peleándome con diferentes aproximaciones nunca he visto ninguna correctamente implementada y, creo, nunca he visto ninguna funcionar hasta que en mi última empresa decidimos implementar durante una época una metodología que llamamos internamente D5

D5 combina, en mi opinión, todas las buenas ideas que se han propuesto en otras metodologías. Es suficientemente estricta como para que todo el equipo tenga claro que hacer en cada momento pero a la vez es suficientemente flexible como para no ahogar en burocracia y rituales. D5 consiste en identificar problemas y ofrecer soluciones lo antes posible.

Los seguidores del movimiento lean, o del desarrollo ágil hace años que tienen una máxima clara “desarrolla un MVP lo antes posible, válida tu idea y aprende”.

D5 divide el desarrollo en 5 fases en las que aunque todo el equipo participa, siempre hay un claro responsable de cada una de ellas. Discovery, Design, Develop, Deploy, Deliver

Discovery

Responsable: Product Owner

odo empieza aquí. En esta fase, la persona responsable del producto está constantemente entrevistándose con usuarios y potenciales usuarios detectando “problemas” (pains).

El objetivo fundamental es escuchar al usuario, entender qué problemas tiene, cómo usa el producto, saber qué alternativas existen y los pros y los contras.

En este punto, he observado muchos errores que se repiten constantemente en diferentes empresas:

1. Ideas felices

La persona responsable de producto tiene ideas felices que añade al backlog sin realizar ningún tipo de discovery:
“Vamos a añadir un chat”. “Creo que si ponemos avatares de colores, la gente nos va a usar más”.

2. Ingenieros ausentes

Aunque estrictamente la fase de discovery es responsabilidad del equipo de producto, es bueno que el equipo de ingeniería esté al corriente de lo que está pasando. Obligarles a dar soporte o asistir a reuniones con clientes cada cierto tiempo es una manera de recordarles que el software es una herramienta para resolver problemas a otras personas.

3. Falta de issue tracker

Creo que es fundamental disponer de un issue tracker automatizado donde los clientes puedan reportar errores y sugerencias de mejora, y sacar métricas constantemente. Si el 90% de los errores están relacionados con una funcionalidad concreta, quizá sea hora de darle un lavado de cara.

4. Soluciones antes de problemas

Lo más importante en esta fase es tener claro que el objetivo de esta fase es identificar PROBLEMAS.

Os contaré una historia. Hace tiempo trabajaba en una app de chat y videollamada. Uno de los clientes nos pidió un “detector de presencia”, el típico icono verde/rojo que indica si un interlocutor está conectado o desconectado a un chat. Implementar esa funcionalidad nos llevó meses y muchos quebraderos de cabeza. Justo antes de entregarla a alguien, se le ocurrió preguntar para qué querían esa funcionalidad, y resultó que la estaban usando para asignar responsables a un determinado chat.

Su problema era que, dada una incidencia, querían asignar a una persona concreta para chatear. ¡Y esto lo hacían marcándose como “no disponibles” manualmente!

Resultó que la asignación de chats era algo que nuestra plataforma ya soportaba, pero no estaba bien documentado. Se solucionó en 1 día, y todo el sistema de presencia quedó en el olvido*.

Design

Personas responsables: product owners, product designer, tech lead

En esta fase, tenemos un problema correctamente identificado, y el equipo debe analizarlo en busca de una solución.

Esta solución no debe ser definitiva, debe ser algo que se pueda desarrollar lo antes posible, sin acumular deuda técnica, y que permita validar con el usuario si la solución propuesta aporta valor resolviendo el problema.

Quizá en esta fase es donde más decisiones críticas se toman, por eso es importante involucrar a todo el equipo.

Es importante recordar que diseño no solo implica interfaz gráfica. Diseño implica pensar en todas las cosas que pueden salir mal, implica pensar en GDPR, implica hablar con el departamento legal, implica hablar con finanzas, implica no tener miedo a comprar soluciones en lugar de reinventar la rueda.

De nuevo, en esta fase he identificado varios problemas recurrentes.

1. Exceso de optimismo

Los product owners son demasiado optimistas. En mi experiencia, es frecuente que siempre piensen en el caso “de oro”, pero nunca se paren a pensar en los casos extremos.

Recuerdo una vez que estábamos implementando una funcionalidad de cash-back.

“De todas las compras que haga el usuario, se le devolverá un 1% a final de mes.”

¿Qué es un mes? ¿Un mes UTC? ¿Un mes en la zona horaria del usuario? ¿Qué pasa si el usuario se mueve? ¿Qué pasa si el usuario compra un coche de 30.000€ el día 31 y lo devuelve el 5 del mes siguiente? ¿Qué pasa si el usuario usa su tarjeta para recargar su cuenta de Revolut? ¿Puede crear dinero infinito? ¿Deberíamos añadir todo esto a los términos y condiciones?

Todo este tipo de cosas y casos raros suelen estar en la cabeza de los ingenieros y rara vez en la cabeza del equipo de producto.

Por ello, es importante que una persona de ingeniería esté encargada de buscar casos raros en esa fase.

2. Subestimar esfuerzo

Otro problema que suelo encontrar en esta fase es que el equipo de producto subestima la complejidad de algunas tareas. Por ello, es conveniente siempre tener a personas del equipo de ingeniería involucradas en el proceso de diseño para dar estimaciones realistas del coste de cada propuesta.

3. No se recorta el alcance

Una vez tenemos una solución pensada, hemos estudiado sus implicaciones, y tenemos una idea del coste de desarrollo, toca hacer lo más difícil: RECORTAR.

Dedicar un tiempo a pensar bien en un problema y su solución no quiere decir que tengamos que implementar todo desde el primer momento. En muchas ocasiones, se pueden hacer concesiones y reducir el alcance de una funcionalidad, dejando partes para etapas posteriores.

En este punto, es importante preguntarse: Sabiendo lo que sabemos, ¿qué es lo mínimo que podemos hacer para que el cliente lo utilice y nos dé feedback sin hipotecar nuestro futuro?

Seguro que poder filtrar por fecha con un datepicker es una idea genial, pero igual podemos usar el input por defecto del navegador en la primera versión. Seguro que crear una herramienta de analíticas en tiempo real es la bomba, pero igual le podemos mandar al usuario un csv por email.

Al final, se trata de hacer concesiones conociendo los riesgos y beneficios de cada decisión.

Develop

Persona responsable: Tech lead

Llegamos a la fase de desarrollo. En esta fase, hay cientos de metodologías sobre las que podría escribir algún día, pero en este texto me limitaré a dar un simple consejo:

1. Ten todo automatizado

Si alguien pregunta: “¿En qué estado está esta tarea?” o si el equipo no tiene claro si un ticket está desplegado, es un claro indicio de que algo va mal.

Herramientas como conventional commits y convenciones de nombrado de ramas permiten que los tickets se asignen y se muevan por el board automáticamente, sin necesidad de que los desarrolladores abran JIRA.

De nuevo, puede que escriba sobre esto porque tengo opiniones muy fuertes sobre dinámicas de desarrollo de software.

Deploy

Persona responsable: Tech lead

Personalmente, considero el despliegue como una fase más del proceso de desarrollo. Es más, si todo está automatizado, no debería existir más allá de las herramientas de gestión de tareas. En todo caso, es en esta fase donde los cambios se despliegan, y es importante no confundirla con la última fase (deliver), en la que los cambios son visibles por el cliente.

Desplegar algo implica tener el código integrado en la rama correspondiente, independientemente de si las funcionalidades implementadas son visibles o no por el usuario final.

En esta fase, el equipo puede realizar pruebas internas (QA) o incluso probar con clientes reales.

De nuevo, el mismo consejo: tener todo automatizado. En nuestro caso, cada commit a cada rama dev y prd se despliega automáticamente en el entorno que corresponda, y no es necesaria ninguna acción extra por parte del equipo de desarrollo.

Además, esta automatización mueve los tickets automáticamente por el board para representar el estado actualizado del ticket en cada momento. (IN REVIEW --> DEPLOYED TO STG)

Deliver

Persona responsable: Product Owner

Aunque parezca increíble, me he encontrado varias veces en equipos donde se desarrolla una funcionalidad y se nos olvida desplegarla para que los clientes puedan usarla.

Por ello, es importante que la persona responsable sea la misma persona encargada de producto (PO), y por ello es importante que disponga de herramientas para entregar la nueva funcionalidad sin recurrir al equipo de desarrollo.

De nuevo, se podrían escribir varios artículos al respecto, pero en mi opinión, lo que mejor funciona es utilizar feature flags, y una vez que la funcionalidad ha sido validada (QA), se puede liberar y entregársela a todos los usuarios.

Conclusión

Personalmente, toda esta metodología me gusta porque puede verse como una cadena de montaje donde los tickets van pasando de una fase a otra, y en cada fase se da libertad al equipo responsable de los detalles de implementación. No se especifica si en la fase de desarrollo se debe usar Kanban, XP o Scrum con sprints de dos semanas.

Se centra en QUÉ debe hacer un grupo de personas en cada fase y no en el CÓMO, y lo hace poniendo al usuario y sus problemas como el origen de todo el ciclo de desarrollo.

Si esta metodología se implementa bien, cada equipo se despierta con una serie de tareas bien definidas en su columna "TODO". Como estas tareas han pasado por una etapa de refinamiento previa, estarán bien pensadas de antemano, por lo que el equipo puede centrarse en desarrollarlas y aportar valor en lugar de perder su tiempo aclarando detalles y haciendo preguntas absurdas.

Comunicación eficiente en empresas tech.

IagoLast — Sun, 06 Nov 2022 18:16:41 +0000

Uno de los puntos de mejora recurrentes en las empresas en las que he trabajado es la comunicación. Muchas empresas trabajan en de forma remota pero no trabajan de forma asíncrona pese a que podrían implementar algunos aspectos del trabajo asíncrono con poco esfuerzo.

En este texto intentaré dar una serie de consejos relacionados con los canales de comunicación y cómo utilizarlos para conseguir una cultura de trabajo asíncrona.

Asíncrono vs remoto

Me gustaría empezar recordando algo que para muchos sigue sin estar claro: trabajar de forma asíncrona es diferente que trabajar en remoto. Conseguir una buena cultura de trabajo asíncrono en una empresa requiere disciplina y esfuerzo por parte de los trabajadores y es una forma de trabajar que no tiene por que gustar a todo el mundo. En mi caso no soy imparcial, ya que siempre me he considerado fiel defensor del trabajo mayoritariamente a asíncrono.

Creo que tener una cultura de trabajo de este tipo ofrece más ventajas que inconvenientes. Empezando por la conciliación laboral ya que por definición la gente pueden establecer sus propios horarios y trabajar cuando se consideran más productivos o simplemente cuando prefieran, aumentando considerablemente la felicidad.

Una empresa asíncrona no sólo se libra de las barreras físicas que tradicionalmente limitan a las empresas no-remotas. Sino que rompe también con las barreras horarias permitiendo la contratación de cualquier persona en cualquier parte del mundo.

Otra ventaja a tener en cuenta es la escalabilidad. Un entorno de trabajo asíncrono exige tener documentación sobre casi todos los procesos y decisiones de una empresa de forma que cualquier nuevo trabajador puede familiarizarse con ellos de forma prácticamente autónoma.

Por último creo que una de las ventajas fundamentales es que la necesidad de documentación mencionada anteriormente obliga al equipo a reflexionar y pensar antes de cada paso y el kaos tiende a crecer más lentamente que con otros entornos.

Consejos de comunicación por nivel.

A continuación voy a dar una serie de consejos que en mi opinión son útiles para orientar la empresa hacia una metodología de trabajo y comunicación asíncrona y cuando y para qué se debe usar cada herramienta ordenados por niveles/herramientas comunes en la mayoría de empresas.

Nivel 0: Reuniones

Las reuniones no gustan a casi nadie. Me incluyo.

En general son una pérdida de tiempo, hay más gente de la necesaria y solamente una minoría participa en las mismas. En cualquier reunión, en un momento determinado uno habla, N escuchan y sólo M encuentran útil lo que se esta diciendo es terriblemente ineficiente.

El discurso suele ser improvisado y la conversación se desvía hacia lugares que no estaban previstos.

Además las barreras linguísticas la timidez o simplemente que no es el momento "adecuado" pueden hacer que personas que participarían de forma activa si se usase otro canal no lo hagan en reuniones perdiendo así parte de la capacidad del equipo.

Por lo general mi recomendación es evitarlas en la medida de lo posible pero si con todo esto sigues pensando en hacer reuniones aquí van una serie de consejos:

1. Invita a la gente con al menos 24h de antelación.

No todos los empleados tienen la misma disponibilidad o los mismos horarios, por lo que es importante planificar las reuniones con antelación para que todos puedan asistir habiendo preparado correctamente el contenido de la misma.

2. Escribe una descripción y un objetivo.

¿De que va la reunión? ¿Qué temas se quieren tratar? ¿Qué opciones se barajan? ¿Qué documentos debería leer para tener todos el contexto suficiente?

3. Limita la duración.

Las reuniones no deben durar más de lo absolutamente necesario. Si se ha planificado correctamente, una reunión de una hora debería ser suficiente para discutir un único tema. Si la reunión se alarga, es probable que se pierda el foco y la eficacia.

En mi experiencia a los 40 minutos la gente deja de atender. No hay problema por dividir una reunión en diferentes reuniones más pequeñas.

4. Limita el número de personas.

Las reuniones más eficientes son aquellas en las que solo están presentes las personas absolutamente necesarias. Si hay más de 8-10 personas en una reunión, es probable que sea demasiado grande y no se pueda llevar a cabo de manera eficiente.

5. Asegúrate de que alguien toma notas.

Durante las reuniones es importante que alguien esté encargado de tomar notas de lo que se discute y se acuerda. De esta forma, se puede tener un registro de lo que se ha hablado y se puede asegurar de que se cumplan los compromisos adquiridos.

Además nos aseguramos de que al menos una persona presta atención constantemente!

6. Establece action items

Para evitar cerrar "en falso" las reuniones es buena idea utilizar los últimos minutos para establecer los pasos a seguir y resumir las conclusiones en una serie de puntos.

Asegúrate de que todos los participantes tengan claro qué se espera que hagan: ¿Cuál es el siguiente paso? ¿Quién se encargará de qué? ¿Deben pasarse a limpio las notas? ¿Actualizar issues? ¿Quién lo hará?

7. Aprovecha sus ventajas

No somos robots. El componente social es importante y a veces es bueno verse las caras y simplemente charlar, quejarse de los problemas y cotillear sobre la empresa con los compañeros. En este sentido las reuniones son el mejor aliado.

Nivel 1: Chat

Dado que Slack es la herramienta de trabajo por excelencia en el mundo de las startups los ejemplos y consejos ofrecidos en esta sección irán orientados a esta herramienta. No obstante la mayoría pueden aplicarse independientemente de la plataforma utilizada.

1. No utilizar el chat como almacenamiento de información.

Por lo general el chat debe utilizarse para hacer preguntas, comentarios y tener conversaciones o discusiones rutinarias pero no debe utilizarse para almacenar información.

He visto bastantes empresas donde los requisitos de un ticket o decisiones importantes se pierden en una conversación por chat. Esto es un error porque por lo general la información en los mismos es difícil de buscar y de encontrar haciendo que se pierda la trazabilidad de las decisiones aumentando el kaos que tanto odiamos.

Puedes pedir links a documentos, exponer argumentos y debatir acaloradamente, pero una vez se toma una decisión o se genera conocimiento, este debe pasar a formar parte de la base de conocimiento de la empresa en lugar de quedarse en el chat.

2. Utiliza hilos de conversaciones

Para evitar fatigar a los participantes de una conversación es recomendable utilizar hilos de forma que la información del canal se mantenga ordenada.

3. Utiliza los estados

Muchas empresas tienen un canal donde los empleados anuncian las vacaciones o avisan de que tienen que salir un momento.

Esto es una mala idea dado que nadie va a buscar entre ese amasijo de mensajes si alguien escribió que tiene que salir o que está enfermo.

Es mucho más eficiente tener una serie de estados y habilitarlos o deshabilitarlos en cada momento. De esa forma si alguien quiere decir algo por slack sabe perfectamente que su interlocutor esta comiendo, esta enfermo o de vacaciones sin tener que bucear en un canal con mensajes de toda la empresa diciendo que salen a hacer un recado.

Nivel 2: Email

El email puede ser visto como un chat asíncrono. Personalmente recomiendo utilizarlo exclusivamente para notificaciones o comunicaciones fuera de la empresa. Para conversaciones irrelevantes se debería utilizar el chat y para discusiones o generar conocimiento se debería usar otra herramienta.

☝️ En mi caso mantengo mi bandeja de entrada está totalmente vacía. En el pantallazo se ve que lo uso a modo te "TODO LIST", donde cada email, normalmente notificaciones de diferentes aplicaciones, representaría una tarea por hacer. En este caso tengo unos libros por leer y revisar una transacción de TripActions.

Nivel 3: Base de conocimiento

Tener una base de conocimientos organizada es uno de los pilares fundamentales para construir una buena cultura de trabajo asíncrono.

Una empresa realmente asíncrona tendrá todo por escrito en una base de conocimiento pública. Personalmente distingo dos grandes subtipos: Los "de producto" y los de "procesos". Los "de producto" contienen toda la información necesaria para desarrollar el software: ¿Cómo es la arquitectura? ¿Cómo se comunican los sistemas? ¿Cómo se debe comportar la UX en ciertas situaciones? Los de proceso hacen referencia a tareas de la propia empresa. ¿Cómo solicitar un ordenador nuevo? ¿Cómo pedir vacaciones? ¿Con quien hablo si quiero cambiar de rol?

1. Es mejor no tener un documento que tenerlo desactualizado

No hay nada mas frustrante que perder el tiempo leyendo información que ya no es relevante. Por eso, en lugar de esforzarse por mantener una base de conocimientos perfecta y completa, es mejor tener una simple pero que esté constantemente en evolución. De esta forma, los empleados tendrán acceso a la información más actualizada y no perderán el tiempo leyendo documentos obsoletos.

Cada vez que se crea un artículo hay que definir un responsable de sus actualizaciones y esa persona debe preocuparse de que el contenido de los mismos este siempre actualizado.

2. Discusiones abajo, resumen actualizado arriba

Es muy común que los requisitos de una tarea evolucionen con el tiempo. Pongamos por caso un ticket: "Actualizar la interfaz de las tarjetas de crédito".

En la descripción del ticket estará una descripción detallada de la tarea que se quiere realizar. Pero no es raro que la gente haga aportaciones en comentarios y se genere una discusión que alterará los requisitos iniciales:

Developer: ¿Esto es solo para tarjetas de crédito?
PM: "Es para credito y débito"
Developer: ¿Cuales son los colores posibles?
PM: "Azul, verde, dorado y negro"
PM: "Visa nos acaba de confirmar está prohibido hacer tarjetas de color dorado sin su consentimiento, los colores son: azul verde y negro"

Toda esta evolución de los requisitos debe reflejarse en el ticket de forma que un developer sólamente necesita leer la descripción para saber qué tiene que hacer y opcionalmente podrá leer los comentarios para saber qué proceso llevo a esos requisitos.

Entender este punto es fundamental porque ahorra muchísimo tiempo y dolores de cabeza.

3. Toma meeting notes

Por cada reunión a la que asistas escribe un documento de meeting notes y persístelo en la base de conocimiento.

Personalmente anoto: Objetivo de la reunión, Participantes, Transcripción y conclusiones.

De esta forma se puede analizar si lo discutido tiene relación con el objetivo de la reunión y si se ha llegado a alguna conclusión relevante.

Resumen

Trabajar en remoto es diferente a trabajar de forma asíncrona
Trabajar de forma asíncrona tiene muchas ventajas
Para crear una cultura de trabajo asíncrona hay que adaptar la comunicación.
- Por defecto todo debe quedar por escrito.
- El uso del chat y el email debe reducirse
- Las reuniones tienen que evitarse en la medida de lo posible.

Abstracciones detalles e interfaces.

IagoLast — Thu, 20 Oct 2022 10:50:29 +0000

Si tuviese que elegir un primer tema a la hora de hablar de arquitectura de software lo tendría claro: Inversión de la dependencia. Este concepto no es nuevo y sin embargo son pocos los que lo aplican en su código. En este artículo me gustaría explicar este concepto de la forma más sencilla posible y poner ejemplos que faciliten su comprensión.

Abstracciones, detalles e interfaces

Antes de entrar en materia es importante definir una serie de conceptos que nos permitirán entender correctamente en que consiste el la inversión de la dependencias.

Abstracción (del latín abstrahere, 'alejar, sustraer, separar') es una operación mental destinada a aislar conceptualmente una propiedad o función concreta de un objeto, y pensar qué es, ignorando otras propiedades del objeto en cuestión.
Detalle es una parte, hecho o circunstancia que contribuye a formar o completar una cosa pero no es indispensable en ella.
Interfaz es la conexión funcional entre dos sistemas, programas, dispositivos o componentes de cualquier tipo, que proporciona una comunicación de distintos niveles de abstracción, permitiendo el intercambio de información.

Para entender estos conceptos vamos a poner un pequeño ejemplo aplicándolos en mundo de la automoción.

Abstracciones en automoción

Para la mayoría de los conductores el motor de sus coches es una abstracción, un concepto del que no necesitan conocer todos los detalles para poder conducir correctamente. Estoy seguro de que muy pocos sabemos si nuestro coche tiene un motor con una configuración de cilindros en línea o una configuración en V. Simplemente necesitamos saber cuatro cosas sencillas como si es diésel o gasolina o cada cuantos kilómetros necesita un cambio de aceite. El coche en sí es una abstracción para los conductores y esta abstracción es posible porque los coches nos ofrecen una serie de interfaces que nos permiten conducirlos sin necesidad de conocer sus detalles de implementación.

¿Os imagináis tener que estudiar absolutamente todos los detalles de cada coche para poder conducirlo? Gracias a las abstracciones podemos pasar de tener que conocer todos los detalles de implementación...

...a tener una serie de interfaces que nos permiten conducir sin necesidad de conocer los detalles

De esta forma podemos conducir cualquier modelo de coche, abstrayéndonos del tipo de motor, del amperaje de la batería, de si es de gasolina o eléctrico o de cuántos cilindros tenga... Es suficiente con conocer la interfaz que nos exponen los fabricantes a los conductores para conducir correctamente el vehículo.

Abstracciones en software

De la misma forma que en la automoción, en el mundo del software también se manejan estos tres conceptos. Por poner un ejemplo, las funciones son abstracciones que conociendo su interfaz (parámetros de entrada y valor de retorno) nos permiten realizas tareas complejas obviando los detalles de implementación.

Por ejemplo sabemos que la función btoa de javascript recibe como parámetro un string y devuelve su representación en base64 pero no necesitamos conocer el RFC donde se define el algoritmo para utilizarla ya que para nosotros es un detalle de implementación sin importancia.

Inversión de la dependencia

¿Qué nos dice el principio de la inversión de la dependencia?

A grandes rasgos nos dice que nuestro código debe depender de abstracciones en lugar de depender de detalles.

En lenguajes como Java este principio suele ser mas sencillo de aplicar porque el propio lenguaje dispone del concepto de interfaz pero en el mundo del frontend su aplicacón suele no ser tan directa.

Una forma sencilla que me gusta utilizar para que mi código no dependa de detalles es crear módulos intermedios que sirvan como abstracción de una implementación concreta.

Pongamos un ejemplo:

// LoginPage.tsx
import ReactGA from 'react-ga';

/**
 * Componente de react que contiene una página de login
 */
export default function LoginPage() {
    /**
     * Función de login que se ejecutará cuando el usuario haga click en el botón de "login"
     */
    function login(e: React.FormEvent<HTMLFormElement>) {
        /**
         * Enviamos eventos a Google Analytics
         */
        ReactGA.event({ category: 'User', action: 'login' });
        // ...
    }

    /**
     * Omitimos la UI dado que no es relevante para este ejemplo
     */
    return <form onsubmit={login}> ... </form>;
}

Imaginemos una página de Login que registra un evento cada vez que el usuario envía el formulario de login al servidor. Esta página utiliza react-ga (Una librería de google analytics sobre React) para monitorizar los eventos del usuario.

El problema de esta aproximación es que los componentes (páginas) están acoplados a google-analytics (react-ga).

Una forma sencilla de eliminar este acoplamiento sería crear un módulo intermedio llamado analytics y que sea este módulo quien dependa de google-analytics:

// LoginPage.tsx
import analytics from './analytics.ts'; // LoginPage solamente depende de analytics

/**
 * Componente de react que contiene una página de login
 */
export default function LoginPage() {
    /**
     * Función de login que se ejecutará cuando el usuario haga click en el botón de "login"
     */
    function login(e: React.FormEvent<HTMLFormElement>) {
        /**
         * ¡¡Enviamos eventos a nuestra abstracción de analíticas!!
         */
        analytics.event({ category: 'User', action: 'login' });
        // ...
    }

    /**
     * Omitimos la UI dado que no es relevante para este ejemplo
     */
    return <form onsubmit={login}> ... </form>;
}

// analytics.ts
import ReactGA from 'react-ga'; // analytics.ts depende de google-analytics

/**
 * Exponemos una función que nos abstrae de la implementación concreta.
 */
function track(args: { category: string; action: string }) {
    ReactGA.event(args);
}

De esta forma el código de los componentes ya no depende directamente de Google analytics, si no que depende de una abstracción llamada analytics cuyo detalle de implementación es desconocido para los componentes.

Aunque puede parecer una tontería hemos desacoplado la lógica de las analíticas del resto de nuestro código y si dentro de unos meses decidimos migrar a cualquier otro proveedor de analíticas basta con hacer cambios en el archivo analytics y si estos cambios mantienen la misma interfaz el resto del código funcionará perfectamente.

Volviendo a la metáfora de los coches, podríamos decir qué mientras los pedales funcionen de la misma forma podríamos llegar a reemplazar el motor por otro diferente de forma totalmente transparente para el conductor.

Resumen

En este artículo hemos visto en que consiste la inversión de la dependencia, los conceptos de abstracción, detalle de implementación e interfaz y cómo se relacionan entre sí. También hemos visto una forma sencilla de abstraer el código de los detalles utilizando módulos intermedios.

Breve introducción a las arquitecturas limpias.

IagoLast — Sun, 09 Oct 2022 12:54:03 +0000

En este artículo trataré de describir de forma muy breve y quizá algo inexacta el concepto de arquitectura limpia en el contexto del software.

"Arquitectura limpia" es el título del libro de Robert C Martin en el que expone y desarrolla el concepto.

Arquitectura de software

Citando a Robert, "La arquitectura de un sistema de software es la forma en la que se organizan los componentes que lo forman y la forma en la que se comunican entre sí".

En proyectos pequeños como prácticas de clase la importancia de tener una buena arquitectura puede no ser muy evidente pero a medida que los proyectos crecen se hace más y más claro su importancia.

Uno de los mejores ejemplos que he visto para ilustrar esta importancia es la siguiente imagen:

¿Qué nudos tienes que deshacer para separar la grapadora del resto de componentes?

Ahora mira esta imagen:

Pues con el software pasa lo mismo, sin entrar en detalles buscamos reducir **la dependencia **de cada una de las piezas y que cada cosa esté en su lugar.

Dependencia

Es muy difícil resumir el concepto de dependencia / acoplamiento de software. Una de las maneras más formales que conozco para medir y cuantificar la dependencia de cada una de las piezas del software es la "conasence" o ¿"Conacimiento"?.

Resumiéndolo mucho podemos decir que "una pieza A depende de una pieza B si cambios en la pieza B afectan de alguna forma a la pieza A"

En la primera foto podemos decir que todos los utensilios están acoplados entre si, porque para mover las tijeras tenemos que mover el bolígrafo y para mover el bolígrafo tenemos que mover la grapadora...

En la segunda foto este acoplamiento se reduce mucho y las tijeras sólo están acopladas al taco de post-it.

Arquitecturas limpias

Las arquitecturas limpias buscan reducir el acoplamiento organizando las piezas en 3 grandes bloques: Dominio, Aplicación y Presentación. La dependencias se organizan de forma que las capas más centrales no saben nada de las capas exteriores.

Dominio

Es donde se definen nuestros objetos de negocio. Por ejemplo si estamos trabajando en una entidad bancaria, una hipoteca o un cliente serían objetos de negocio.

Estos objetos se pueden representar con clases y no tienen absolutamente ninguna dependencia (no importan otros archivos).

export default class Mortgage {
    constructor(amount, years, rate) {
        this.amount = amount;
        this.years = years;
        this.rate = rate;
    }
}

export default class Client {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }
}

Aplication

Por encima del dominio tenemos las reglas de negocio. Estas reglas conocen los objetos de dominio y junto a estos definen nuestra lógica de negocio

Por ejemplo "No conceder préstamos a más de 20 años vista a personas mayores de 40 años"

/**
 * Esta función recibe como parámetro una hipoteca y un cliente y devuelve
 * true o false según se pueda conceder o no esta hipoteca. 
 *
 * Cambios en la clase hipoteca o en la clase Cliente pueden 
 * afectar a esta función y decimos que están acopladas.
 *
 * Siendo estrictos podemos decir que tenemos 
 * [conacimiento de tipo](https://connascence.io/type.html) 
 * en los parámetros
 *
 */
function checkIfMortageCanBeGranted(mortage, client) {
    if(client.age > 40 && mortage.years > 20) {
        return false;
    }

    // ... Asumimos que habría mas reglas de negocio

    // Finalmente devolvemos true para conceder la hipoteca
    return true;
}

Presentación

En esta última capa tendremos toda la lógica necesaria para presentar nuestra lógica de negocio al cliente final. Podríamos escribir una aplicación en React, una aplicación en Vue o incluso un asistente de voz escrito en javascript.

Nuestra lógica de negocio y nuestros objetos de dominio son iguales independientemente de la tecnología elegida para la vista y pueden ser utilizados por una app escrita en Angular, por una app escrita en Vue o por una app escrita en React. Además podemos escribir tests unitarios que comprueben este comportamiento de forma totalmente aislada para verificar que los requisitos son correctos.

De nuevo, lo importante es que gracias a aplicar una arquitectura limpia tanto los objetos de dominio no están acoplados a la lógica de negocio y la lógica de negocio a su vez es independiente de la presentación.. Esto hace que cuando tengamos que mantener una aplicación grande tengamos muchísimo más claro qué nudos hay que deshacer para reemplazar la grapadora por una más moderna.

Enlaces

El futuro de la programación: Programar menos.

IagoLast — Sat, 24 Sep 2022 09:15:12 +0000

Twillio abre la veda

El pasado 21 de septiembre Twillio publicaba la versión 9 de su SDK para Java.

Además de contener breaking changes, en la release notes se puede leer un párrafo que indica la dirección de la nueva revolución tech.

Java Helper is now auto-generated via OpenAPI with this release. This enables us to rapidly add new features and enhance consistency across versions and languages.

OpenAPI

Una de las revoluciones silenciosas en el mundo de la programación ha sido la aparición de OpenAPI (La versión 3 se publicó en 2017).

OpenAPI es un estándar abierto para describir APIs RESTful especificando formalmente que define el formato de los datos que se intercambian entre el cliente y el servidor. OpenAPI se basa en JSON Schema, un tema sobre el que probablemente escriba pronto, un estándar para describir datos en formato JSON.

La principal ventaja de OpenAPI es que puede autogenerarse. Esto significa que podemos tener gratis documentación y el código clientes a partir de nuestro código backend! Además esta documentación y nuestro código se mantienen sincronizados y actualizados automáticamente.

Herramientas como readme.io son compatibles con OpenAPI y te permiten tener un portal de documentación completo a partir de la especificación de la API en segundos.

Una de las cosas que más me sorprende es que son capaces de autogenerar clientes para un montón de lenguajes!

Autogenerando clientes Typescript

En el caso de Typescript lo hacen mediante un paquete llamado api que hace que me explote la cabeza.

Actualmente están trabajando en la versión 5 y sospecho que va a cambiar la forma de trabajar de muchos.

Para generar el cliente typescript de una API basta con ejecutar el comando desde npx indicando la url de la spec en OpenAPI (en el momento de escribir estas lineas estaba en la beta de la versión 5.

npx api@5.0.0-beta.3 install https://api.timetime.in/v3/api-docs

Esto se descarga la especificación y genera una librería desde cero con todos los métodos de la API incluyendo los tipos de los parámetros de entrada y de los valores retornados. Además la publica en npm dentro de su namespace @api/

El único problema es el versionado. A día de hoy no he visto cómo se puede instalar una versión específica del cliente de una API por lo que creo que las builds no serían reproducibles.

Evidentemente, al tratarse de una beta no lo he probado en producción pero creo que en unos años será el estado del arte a la hora de comunicar clientes y servidores matando a GraphQL e incluso a alternativas tan interesantes como gRPC.

En resumen: No perdais el tiempo! Autogenerad la spec de vuestra API a partir del código del servidor, autogenerad la documentación y autogenerad los SDKs y los clientes.

Las cosas por sus nombre

IagoLast — Sun, 04 Sep 2022 15:22:24 +0000

Ayer fue la #pulpoCon22 que se ha consolidado como como uno de mis eventos favoritos y que creo que dará mucho de que hablar en el futuro.

Entre otras cosas tuve la oportunidad de desvirtualizar al gran @talkingbit1 que me confesó que el secreto del éxito es escribir algo todos los días y pude asistir a una charla sobre testing de @nuria_codes donde entendí que dijo que los nombres de los tests no importan y que dedicamos demasiado esfuerzo y tiempo a ponerle apodos a las cosas en lugar de reflexionar sobre sus características.

En parte estoy de acuerdo y me gustaría recomendar leer las reflexiones del gran Richard Feynman donde habla entre otras cosas, sobre la diferencia entre nombrar vs conocer.

Es cierto que para hablar con alguien de forma efectiva y eficiente es recomendable disponer de un lenguaje común, pero es importante recordar que al menos en cuanto a testing los nombres son lo de menos. Lo importante es conocer las características, comportamiento y ventajas e inconvenientes de cada tipo de test independientemente del nombre que le demos.

En particular a la hora de hablar de un test me gusta acotar las siguientes características:

Sensibilidad: Probabilidad de fallar si existe un error en el código.
Especificidad: Probabilidad de dar por válido un comportamiento correcto del código.
Fragilidad: Probabilidad de que un test de falsos positivos. Se compone a su vez de:
- Estabilidad: Probabilidad de que un test de el mismo resultado en diferentes ejecuciones.
- Flexibilidad: Tolerancia de un test a cambios en la implementación que no afectan al comportamiento.
Precisión: Mide cómo de complicado es identificar la fuente del error si el test falla.
Mantenibilidad: Mide cómo de complicado es actualizar o modificar el código del test.
Velocidad: Mide cuánto tiempo tarda el test en ejecutarse.
Profundidad : Indica el número de componentes y dependencias que se ejecutan en el test.

Con estas características encima de la mesa creo que uno de los debates más frecuentes es la discusión entre qué es un test unitario y qué es un test de integración. Algunos consideran que un test unitario prueba sólo una unidad (profundidad cero) y otros como Fowler introducen el concepto de test unitarios sociables para poder denominar tests unitarios a tests con profunidad N.

Este dogmatismo en cuanto a nombres y "buenas prácticas" hace que algunos se obsesionen con cumplir la máxima de "la pirámide de tests dice que tenemos que tener muchos test unitarios" y llenan la base de código de tests que no sirven absolutamente para nada mientras que jamás probarán un caso de uso completo porque "esos tests son frágiles y es malo que un test sea frágil"

En resumen, aunque llamar a las cosas por su nombre es una buena idea para tener una conversación fluida por desgracia todavía no tenemos unos nombres establecidos en la industria.

Mientras eso no ocurra, si queremos evitar situaciones donde se imponga el fanatismo y el dogmatismo, lo mejor sería que antes de cada discusión nos aseguráramos de que todos los participantes conocen las características de los tipos de tests de los que vamos a hablar para poder centrar la conversación en las ventajas y riesgos que asumimos con cada uno de ellos y poder usar la cabeza para determinar cuál es la mejor estrategia de testing para nuestro caso particular en lugar de seguir recetas y soluciones milagrosas totalmente a ciegas.

Muy breve introducción al testing

IagoLast — Thu, 01 Sep 2022 13:31:30 +0000

Cuanto más programo más convencido estoy de que el testing es una de las herramientas más útiles que tenemos los programadores a nuestra disposición. No conozco a nadie que haga tests correctamente que no este de acuerdo. Los tests automáticos ahorran tiempo, dinero, reducen la cantidad de errores, ayudan a diseñar, a razonar sobre el software, permiten eliminar deuda técnica con mayor seguridad y hasta sirven como especificación formal de los requisitos del software.

¿Qué es un test?

Imagínate que acabas de escribir un fragmento de código...

¿Cómo sabes que funciona? ¿Cómo sabes que hace lo se espera que haga?

La mayoría de la gente responderá que lo sabe porque lo ha probado. Porque han abierto el navegador, navegado hacia cierta sección de la app, rellenado un input, han hecho click en un botón y han comprobado que la app reacciona correctamente a esa interacción del usuario.

Seguramente tú mismo, has puesto un console.log para comprobar de alguna forma que una función hace lo que esperas. Especialmente si la función no tiene asociada ninguna interfaz gráfica por ejemplo escribir una función que sume dos números

function sum(a, b) {
    return a + b
}

En estos casos la mayoría de developers acabe utilizando la consola para comprobar que la función es correcta:

console.log( sum( 1, 2) )   // 3
console.log( sum( 2, 2) )   // 4

Vamos a analizar estos procesos... tanto en el primero donde el desarrollador prueba manualmente la app desde el navegador como en el de los console logs se repiten unos patrones comunes:

Se identifica la funcionalidad que se quiere probar.
Se ejecuta el software que contiene esa funcionalidad bajo unas condiciones controladas.
Se comprueba que el resultado obtenido es igual al resultado esperado.

Estoy seguro que más de uno identifica este comportamiento, si es así enhorabuena ya estás haciendo tests, el siguiente paso es convertir estos tests manuales en tests automáticos.

Tests automáticos

La pregunta del millón es: ¿Podemos escribir un software que compruebe que otro software funciona correctamente?

En un principio puede parecer una locura escribir código para que pruebe otro código de forma automática. Sin embargo a medida que el software crece, las ventajas que ofrecen los tests automáticos son evidentes:

Ayudan a detectar errores fácilmente.
Nos sirven como documentación.
Ayudan a razonar sobre el código y a mejorar el diseño.

Tests runners

Supongamos que estamos convencidos de hacer tests automáticos. Lo primero que necesitamos es lo que se llama un "test runner", por definirlo de forma sencilla un test runner es una herramienta que nos permite definir y ejecutar nuestros tests automáticos. En el mundo del frontend los más conocidos son jest y mocha.

Estos frameworks nos ofrecen entre otras cosas una función llamada test que nos permite nombrar, definir y ejecutar tests de forma sencilla o la función expect para comprobar que los valores obtenidos cumplen los requisitos esperados.

test('LA DESCRIPCION DEL TEST VA AQUI', () => {

// La implementación del test va aquí

});

Los tests runners también nos ayudan a ejecutar los tests y generan un informe diciendo cuántos tests han tenido el resultado esperado y cuántos de ellos han fallado.

Ejemplo sencillo: La función replace

Los strings de javascript heredan una función replace de su prototipo que recibe dos parámetros, un string a reemplazar y el string que lo reemplazará.

¿Cómo lo probarías?

La respuesta es siempre la misma: Haz exactamente lo mismo que harías si tuvieses que probar manualmente.

En este caso seguramente definirías un string, llamarías al método replace y comprobarías (mediante un console.log) que el string final es el esperado. En el caso de los tests automáticos el proceso es el mismo:

// Utilizamos la funcion "test" para dar nombre a la prueba e implementarla
test('should replace a string with the new given string', () => {
    // Creamos un string conocido para ejecutar nuestra prueba
    const template = 'hello world';
    // Ejecutamos la función que queremos probar pasándole unos parámetros conocidos
    const actual = template.replace('world', 'testing');
    // Comprobamos que el resultado es el esperado
    expect(actual).toEqual('hello testing');
});

y eso es todo! Hemos escrito nuestro primer test.

Evidentemente esto no es mas que una pequeña introducción, pero la esencia es siempre la misma, intentar automatizar el proceso que seguiríamos para probar una funcionalidad manualmente.

Conclusiones

Inconscientemente los programadores realizan tests manuales.
Estos tests se pueden llegar a automatizar.
Los tests automáticos son una de las mejores herramientas disponibles actualmente.