Dic 2027 → Abr 2028
Learn
Testing
Desde cero hasta dominar testing en frontend con fundamentos que escalan directo al backend. Sin saltar etapas.
16
Semanas
240h
Totales
5
Fases
15h
Por semana
Scroll
01 — Fases del programa
Roadmap completo
5 fases progresivas desde fundamentos mentales hasta testing en backend.
Fase 1
Por que testeamos?
Semana 1-2
Confianza al refactorizar, documentacion viva, catch de regresiones. Testing no es solo "encontrar bugs".
Fase 1
La Piramide de Testing
Semana 1-2
Unit → Integration → E2E. Mas unitarios, menos E2E. Costo vs velocidad de feedback.
Fase 1
Que hace un buen test
Semana 1-2
AAA pattern (Arrange, Act, Assert). Tests deterministas, aislados, rapidos y con nombres descriptivos.
Fase 2
Vitest / Jest
Semana 3
Setup basico, describe/it/expect, matchers comunes. Vitest para Vite projects, Jest para el resto.
Fase 2
Funciones puras
Semana 3
Empieza aqui. Input → Output predecible. Cero side effects. El testing mas facil que existe.
Fase 2
Mocks, Stubs & Spies
Semana 4
vi.fn(), vi.mock(), vi.spyOn(). Aislar dependencias externas (APIs, localStorage, modulos).
Fase 2
Testing de Componentes
Semana 5
React Testing Library o Vue Test Utils. Testear comportamiento, no implementacion. getByRole sobre getByTestId.
Fase 2
Hooks & Custom Logic
Semana 6
renderHook de RTL. Testear useEffect, useState, custom hooks sin renderizar UI completa.
Fase 2
Peticiones HTTP
Semana 7
Mock Service Worker (MSW) para interceptar fetch/axios. Tests realistas sin servidor real.
Fase 2
Angular Testing
Semana 8
Testing en Angular tiene sus propias herramientas. TestBed para configurar el módulo de test, Spectator para simplificar setup, ng-mocks para aislar dependencias sin boilerplate.
Fase 3
Integration Testing
Semana 9
Testear multiples unidades juntas: formularios completos, flujos de estado con context/store, interaccion entre componentes.
Fase 3
Cypress
Semana 10
E2E en el browser real. cy.visit, cy.get, cy.intercept. Testear flujos criticos: login, checkout, forms complejos.
Fase 3
Playwright
Semana 11
Alternativa moderna a Cypress. Multi-browser nativo, mejor para CI/CD, mas rapido. Elige uno y profundiza.
Fase 3
Que testear con E2E (y que no)
Semana 11
Flujos criticos de negocio (auth, pago), navegacion entre paginas, formularios end-to-end. NO cada variante de UI (eso es unit), NO casos edge (eso es integration), NO logica interna de componentes.
Reglas E2E SI: Auth, pagos, navegacion, forms completos
NO: Variantes UI, casos edge, logica interna
NO: Variantes UI, casos edge, logica interna
Fase 4
Accessibility Testing
Semana 12
jest-axe para checks automaticos. Queries semanticas en RTL. Testing con roles ARIA reales.
Fase 4
Visual Regression
Semana 13
Snapshots de UI con Storybook + Chromatic o Percy. Detectar cambios visuales no intencionados.
Fase 4
Coverage Reports
Semana 13
Istanbul/V8 coverage. No busques 100%, busca cubrir paths criticos. Coverage como guia, no como meta.
Fase 4
TDD en practica
Semana 14-15
Red → Green → Refactor. TDD no se aprende en 1 semana — se internaliza con 2 semanas de práctica activa. Semana 14: ciclos cortos con funciones puras. Semana 15: TDD en componentes y servicios reales.
Fase 4
Contract Testing
Semana 15
Cuando el frontend y el backend son equipos distintos (o micro-frontends), los tests de contrato garantizan que la API que esperas consume la que el backend expone. Pact es el estándar.
Fase 4
Testing en CI/CD
Semana 16
GitHub Actions corriendo tests en cada PR. Bloquear merge si tests fallan. Parallelization para velocidad.
Puente
Puente hacia Backend
Transicion
Los fundamentos que aprendiste aplican directo al backend. El mindset, la piramide, AAA, mocks, coverage — todo es igual. Solo cambian las herramientas y lo que testeas.
Fase 5
Jest para Node.js
Ver durante Backend Roadmap · 2026
Unit testing de funciones, services, utilidades. Mismo Jest, diferente entorno. Sin DOM, sin browser APIs.
Fase 5
Mockeando DB & Servicios
Ver durante Backend Roadmap · 2026
jest.mock() para repos/ORMs. Test doubles para llamadas a base de datos. Testear logica sin SQL real.
Fase 5
API / Integration Tests
Ver durante Backend Roadmap · 2026
Supertest para testear rutas HTTP reales contra una instancia del servidor. Seed de datos y cleanup.
Fase 5
Testing de modulos Python/otros
Ver durante Backend Roadmap · 2026
Pytest (Python), Go test, JUnit (Java). Los conceptos son identicos. Las APIs son distintas.
02 — Semana tipo
Distribucion semanal
15 horas semanales divididas en bloques diarios de 3 horas (Lunes a Viernes). Cada dia: teoria + practica del concepto.
Distribucion diaria · 3h
📖 Teoria + documentacion del concepto1h
⌨️ Implementar tests en proyecto real1h 30m
📝 Revisar, refactorizar y documentar30m
Contenido de la semana
- Testing como inversión, no overhead: la curva de costo-beneficio de bugs encontrados en desarrollo vs producción — los números que convencen a cualquier equipo
- La pirámide de testing: Unit → Integration → E2E — velocidad de feedback, costo de mantenimiento y ratio recomendado por nivel
- Confianza al refactorizar: el argumento más poderoso para adoptar testing — cambiar código sin miedo porque los tests te avisan si rompiste algo
- TDD intro: Red → Green → Refactor como ciclo de diseño, no solo de verificación — por qué el orden importa y qué pasa si lo omitís
- El trofeo de testing (Kent C. Dodds) vs la pirámide clásica: cuándo más integración que unit tiene sentido en el ecosistema moderno
- Anti-patrones de testing desde el inicio: tests frágiles que prueban implementación, tests sin assertions, tests lentos que nadie corre
Fuentes de referencia
Libro
The Art of Unit Testing
Roy Osherove. Introducción: qué es un unit test, por qué importa y cuál es la diferencia entre un test bueno y uno que solo genera ruido. El punto de entrada más claro para empezar.
Libro
Unit Testing: Principles, Practices and Patterns
Vladimir Khorikov. Cap 1: The goal of unit testing — el único libro que empieza con "qué queremos lograr" antes de enseñar herramientas. Leer este capítulo cambia la perspectiva completa.
Abrir →Principios
Testing Library — Guiding Principles
testing-library.com/docs/guiding-principles — Los principios que guían RTL definen qué testear y cómo: testear comportamiento observable, no implementación interna.
Abrir →YouTube
Kent C. Dodds — Write tests, not too many, mostly integration
El blog post/talk que cuestionó la pirámide clásica y propuso el trofeo de testing. El contexto de por qué el ecosistema moderno favorece integration tests.
Contenido de la semana
- AAA (Arrange, Act, Assert): la estructura de 3 partes que hace un test legible — cómo aplicarla conscientemente y por qué romperla genera confusión
- Tests deterministas: el mismo input siempre produce el mismo output — por qué Math.random(), Date.now() y timezone rompen los tests y cómo aislarlos
- Tests aislados: cada test es una isla — setup con beforeEach, teardown con afterEach, por qué compartir estado mutable entre tests genera falsos positivos
- Nombres descriptivos: "should return X when Y given Z" — el test como documentación ejecutable que explica el comportamiento sin leer el código
- Tests rápidos: por qué un test que tarda más de 100ms ya es sospechoso — identificar y eliminar latencia artificial (I/O, red, timers reales)
- Un assertion por comportamiento: tests que verifican una sola cosa son más fáciles de diagnosticar cuando fallan — cómo dividir un test con múltiples expects
Fuentes de referencia
Libro
The Art of Unit Testing
Osherove. Cap 2: A first unit test — la guía más clara sobre AAA con el primer test real paso a paso. Incluye el razonamiento detrás de cada parte de la estructura.
Libro
Unit Testing: Principles, Practices and Patterns
Khorikov. Cap 3: The anatomy of a unit test — formaliza AAA, explica Given/When/Then como alternativa y detalla por qué un test debe tener exactamente un Act.
Docs
Vitest — Getting Started
vitest.dev/guide — Setup de Vitest con ejemplos de describe/it/expect que siguen el patrón AAA. La base para los tests de las siguientes semanas.
Abrir →YouTube
ArjanCodes — Why I Write Tests Before Writing Code
TDD intro con Python pero completamente aplicable a TypeScript. Cubre nomenclatura, AAA y por qué el orden Red → Green → Refactor importa.
Contenido de la semana
- Vitest vs Jest: cuándo usar cada uno — Vitest para proyectos Vite/Angular moderno, Jest para el ecosistema legacy/Node — la razón técnica es la compatibilidad con ESM
- Setup de Vitest en Angular: vitest.config.ts, globals: true, jsdom environment, coverage provider V8 — la configuración mínima que funciona
- describe/it/expect: la anatomía de un test file — agrupación lógica con describe, tests atómicos con it, assertions con expect — convenciones de nomenclatura
- Matchers esenciales: toBe vs toEqual (referencia vs valor profundo), toBeNull, toBeUndefined, toContain, toHaveLength, toThrow — cuándo usar cada uno
- Primeros tests sobre funciones puras: utilidades de formateo, validadores, transformadores de datos — el lugar más fácil para empezar porque no hay dependencias
- watch mode y coverage básico: vitest --watch para feedback inmediato en desarrollo, vitest --coverage para ver qué líneas nunca se ejecutan
Fuentes de referencia
Libro
The Art of Unit Testing
Osherove. Cap 2: A first unit test — el primer test real con setup, el primer matcher y el primer refactor guiado. El punto de partida más accesible.
Docs
Vitest — API Reference
vitest.dev/api — Referencia completa de la API de Vitest. La fuente de verdad para matchers, configuración y utilidades. Bookmarkear para el resto del roadmap.
Abrir →YouTube
Fireship — Vitest Crash Course
Setup y primeros tests en menos de 15 minutos. El formato más conciso para entender la herramienta antes de profundizar en la documentación.
Tool
vitest — Snapshot Testing
vitest.dev/guide/snapshot — Snapshot testing como alternativa a matchers complejos en outputs grandes. Cuándo usarlos y cuándo evitarlos.
Abrir →Contenido de la semana
- La diferencia crítica: Mock (verifica comportamiento), Stub (reemplaza respuesta), Spy (observa sin reemplazar) — confundirlos genera tests incorrectos que pasan cuando no deberían
- vi.fn(): crear funciones ficticias, controlar retornos con mockReturnValue/mockResolvedValue, verificar llamadas con toHaveBeenCalledWith y toHaveBeenCalledTimes
- vi.mock(): reemplazar módulos enteros — por qué mockear solo en el boundary de la aplicación y no dentro de la lógica de negocio
- vi.spyOn(): observar objetos reales sin reemplazarlos, restaurar el comportamiento original con mockRestore() — útil para módulos del sistema (Date, Math, console)
- Cuándo mockear: localStorage, fetch, Date.now(), Math.random() — el principio es mockear solo lo que no controlas, no lo que es tuyo
- Anti-patrón del over-mocking: cuando todo está mockeado no estás probando tu código sino los mocks mismos — el test que siempre pasa aunque el código esté roto
Fuentes de referencia
Libro
Unit Testing: Principles, Practices and Patterns
Khorikov. Cap 5: Mocks and test fragility — la distinción más importante del libro. Por qué demasiados mocks generan tests que no protegen de regresiones reales.
Abrir →Docs
Vitest — vi utilities
vitest.dev/api/vi — Referencia completa de vi.fn, vi.mock, vi.spyOn con ejemplos de cada variante de uso. La documentación más práctica disponible.
Abrir →YouTube
Jack Herrington — Mocking in Vitest
La diferencia práctica entre mock, stub y spy con código real. Uno de los pocos videos que explica el anti-patrón del over-mocking con ejemplos.
Guía
Vitest — Mocking Guide
vitest.dev/guide/mocking — Guía oficial de mocking: módulos, timers, globals, Date. La referencia para los casos más complejos de aislamiento.
Abrir →Contenido de la semana
- La filosofía de RTL: testear comportamiento observable del usuario, no implementación interna — por qué no se testea state, className ni refs directamente
- Queries semánticas y su prioridad: getByRole > getByLabelText > getByText > getByTestId — el orden que RTL recomienda y por qué cada escalón tiene menor semántica
- getByRole con roles ARIA: button, heading, listitem, checkbox, textbox, dialog — accesibilidad y testabilidad son la misma decisión de diseño
- userEvent vs fireEvent: userEvent simula interacciones reales (click, type, tab con bubbling y efectos secundarios), fireEvent despacha eventos directos — cuándo importa la diferencia
- screen vs render: por qué screen es preferible a desestructurar el resultado de render — el cambio que simplifica el mantenimiento de tests
- Testear estados de loading y error: findBy (async), waitFor, componentes con estados condicionales de UI — los casos donde getBy falla y findBy es obligatorio
Fuentes de referencia
Libro
Unit Testing: Principles, Practices and Patterns
Khorikov. Cap 4: The four pillars of a good unit test — resistencia al refactoring es el pilar que RTL implementa al testear comportamiento y no implementación.
Docs
Testing Library — Queries
testing-library.com/docs/queries/about — La guía definitiva de queries, su prioridad y el razonamiento detrás de cada una. El documento más importante de RTL.
Abrir →YouTube
Kent C. Dodds — React Testing Library Crash Course
El autor de RTL explica su filosofía directamente. El video donde queda claro por qué getByRole es mejor que getByTestId.
Tool
Testing Playground
testing-playground.com — Herramienta visual que analiza tu DOM e indica cuál es la query correcta. La forma más rápida de aprender qué query usar en cada caso.
Abrir →Contenido de la semana
- renderHook de RTL: testear custom hooks sin renderizar un componente completo — result.current para acceder al valor retornado, rerender para actualizar props
- act(): envolver updates de estado para que React procese todos los efectos síncronos antes del assertion — cuándo es obligatorio y cuándo RTL lo aplica automáticamente
- Testear useEffect con side effects: cleanup functions, dependencias cambiantes, stale closures — el caso más complejo de hooks en testing
- Custom hooks como unidades testeables: un hook bien diseñado es testeable sin componentes — el principio de separar lógica de presentación
- Hooks asíncronos: waitFor, findBy, act con promesas — patrones para hooks que hacen fetch o esperan timers
- Anti-patrón: testear hooks internos de un componente desde afuera — solo testea el comportamiento observable del componente, no cómo se implementa internamente
Fuentes de referencia
Docs
Testing Library — renderHook
testing-library.com/docs/react-testing-library/api#renderhook — Referencia oficial de renderHook con todos los casos de uso: hooks síncronos, asíncronos y con context.
Abrir →Docs
Testing Library — userEvent v14
testing-library.com/docs/user-event/intro — La API moderna de userEvent v14 que simula interacciones reales del usuario. Reemplaza a fireEvent en la mayoría de los casos.
Abrir →YouTube
Laith Harb — Testing Custom React Hooks
Ejemplos prácticos con casos síncronos, asíncronos y con context. El video más completo sobre renderHook disponible en YouTube.
Tool
@testing-library/react
npmjs.com/@testing-library/react — La herramienta principal. renderHook, act, fireEvent, screen y waitFor son las APIs que se usan en el 90% de los tests de React.
Abrir →Contenido de la semana
- Por qué MSW: intercepta en el nivel de red con Service Worker, no en el código — los componentes no saben si hay un mock, los tests son idénticos a producción
- Setup de MSW 2.x: setupServer para Node (Vitest/Jest), setupWorker para browser (Storybook), la diferencia entre los dos entornos y cuándo usar cada uno
- handlers con http.get/http.post: retornar respuestas tipadas con HttpResponse, simular errores con status codes reales, JSON body y headers
- server.use() dentro de un test: override temporal de handlers para casos específicos — probar estados de error (500, 404) y loading sin modificar el handler global
- Testear componentes con datos remotos: render → waitFor(findBy) → verificar UI — el patrón completo con MSW como infraestructura
- MSW vs vi.fn() para fetch: por qué MSW es superior — testea la URL real, los headers, el body y la deserialización, no solo el retorno de la función
Fuentes de referencia
Docs
MSW — Documentation
mswjs.io/docs — Documentación oficial de MSW 2.x con guías de setup para Vitest, Jest y Node. Incluye la diferencia entre handler de REST y GraphQL.
Abrir →YouTube
Jack Herrington — Mock Service Worker Tutorial
El ejemplo más completo de MSW en un proyecto real con React y TypeScript. Cubre setup, handlers, overrides y el patrón completo de test con componentes.
Guía
MSW — REST Handlers
mswjs.io/docs/network-behavior/rest — Catálogo de handlers REST con ejemplos de respuestas exitosas, errores y delays simulados.
Abrir →Tool
msw
npmjs.com/msw — La librería que hace que los tests de componentes con fetch sean deterministas sin modificar el código de producción.
Abrir →Contenido de la semana
- TestBed: el módulo de testing de Angular — configureTestingModule, compileComponents, imports y providers — el boilerplate mínimo para un test de componente
- ComponentFixture: el wrapper que da acceso al componente, el DOM nativo y la instancia real — fixture.detectChanges() como paso obligatorio antes de los assertions
- async y fakeAsync: el desafío de las operaciones asíncronas en Angular — tick() y flush() para controlar el tiempo, HttpClientTestingModule para interceptar HTTP
- Spectator: simplifica el boilerplate de TestBed con createComponent — reduce el setup en un 70% y provee helpers para queries y event dispatching
- ng-mocks: aislar componentes de sus dependencias sin configurar cada módulo — MockComponent, MockService, MockPipe, MockDirective sin esfuerzo
- Testing de servicios Angular: inject() en tests con TestBed.inject(), HttpTestingController.expectOne() y flush() para responder requests HTTP
Fuentes de referencia
Docs
Angular — Testing Guide
angular.dev/guide/testing — Guía oficial de testing en Angular con TestBed, ComponentFixture, HttpClientTestingModule y fakeAsync. La fuente más actualizada.
Abrir →Docs
Spectator — Documentation
ngneat.github.io/spectator — Documentación de Spectator: la alternativa más popular al TestBed puro. Cubre createComponent, createService y createDirective.
Abrir →YouTube
Joshua Morony — Testing in Angular
La serie más completa y actualizada de testing en Angular moderno. Cubre TestBed, Spectator, ng-mocks y testing de Signals.
Tool
ngneat/ng-mocks
github.com/ngneat/ng-mocks — La herramienta más poderosa para aislar dependencias en tests de Angular. MockComponent y MockService eliminan el módulo de configuración manual.
Abrir →Contenido de la semana
- Qué es Integration Testing: múltiples unidades trabajando juntas — el nivel donde se encuentran la mayoría de los bugs reales de una aplicación
- Formularios completos con RTL: render → llenar campos con userEvent.type → submit → verificar side effect (llamada API mockeada, cambio de ruta, mensaje de confirmación)
- Testear flujos de estado con Zustand/Redux: render con store real, dispatch de actions, verificar UI resultante — no mockear el store, testear el flujo completo
- Interacción entre componentes: parent-child event propagation, context provider wrapping, comunicación entre componentes como unidad integrada
- Cuándo integration sobre unit: cuando el riesgo está en cómo las piezas interactúan, no en cómo funciona cada pieza por separado
- Setup de integration tests: beforeAll para datos compartidos entre tests del mismo flujo, cleanup con afterEach, msw como infraestructura de red
Fuentes de referencia
Libro
Unit Testing: Principles, Practices and Patterns
Khorikov. Cap 8: Why integration testing — el argumento más sólido sobre cuándo necesitás cada nivel y por qué integration testing complementa (no reemplaza) unit testing.
Docs
Testing Library — userEvent v14
testing-library.com/docs/user-event/intro — userEvent para flujos de formularios completos y realistas: type, click, selectOptions, upload — el toolkit para integration tests.
Abrir →YouTube
Kent C. Dodds — Static vs Unit vs Integration vs E2E Testing
El mejor video sobre cuándo usar cada nivel de testing con trade-offs reales. El contexto conceptual que hace que los tests de integración tengan sentido.
Ejemplo
Testing Library — Form Examples
testing-library.com/docs/example-input-event — Ejemplos reales de tests de formularios de principio a fin con userEvent y MSW.
Abrir →Contenido de la semana
- Por qué Cypress: browser real, recarga automática, time travel debugging con screenshots por cada step — el DX más alto del mercado para E2E
- cy.visit(), cy.get(), cy.contains(), cy.click(), cy.type(): los comandos fundamentales con la sintaxis encadenada y el retry automático integrado
- cy.intercept(): interceptar y controlar respuestas HTTP sin MSW — cy.intercept("GET", "/api/user", { fixture: "user.json" }) como pattern base
- fixtures: datos JSON reutilizables en cypress/fixtures/, cy.fixture() para cargar datos y evitar duplicación entre tests de la misma suite
- Page Objects: patrón de abstracción para selectors y acciones repetibles — una clase por página, métodos que representan acciones del usuario
- Configuración para CI: cypress run vs cypress open, baseUrl en cypress.config.ts, variables de entorno, retries en CI para tests flaky
Fuentes de referencia
Docs
Cypress — Documentation
docs.cypress.io — La documentación oficial más completa del ecosistema E2E. Guías por caso de uso: auth, intercept, fixtures, custom commands.
Abrir →YouTube
Cypress.io — Canal oficial
Tutoriales oficiales por caso de uso real: auth flows, intercept, component testing. El contenido más confiable y actualizado de Cypress.
YouTube
Jack Herrington — Cypress Crash Course
El más completo para empezar con Cypress en un proyecto real. Cubre setup, intercept, fixtures y CI en un solo video.
Tool
cypress
npmjs.com/cypress — La herramienta de E2E con mejor DX disponible para frontend. Instala cypress y abre la UI de Cypress para el primer test antes de leer la documentación.
Abrir →Contenido de la semana
- Playwright vs Cypress: sin limitación de same-origin, multi-tab nativo, file downloads sin workarounds, mejor paralelización por defecto — cuándo Playwright gana
- Multi-browser: Chromium, Firefox y WebKit (Safari engine) en el mismo test — detectar incompatibilidades cross-browser que Cypress no puede encontrar
- page.goto(), page.click(), page.fill(), page.locator(): la API de Playwright con locators semánticos — getByRole, getByText, getByLabel integrados
- expect(page).toHaveURL(), .toHaveTitle(), .toBeVisible(): los matchers de Playwright — una API de assertions integrada sin jest ni vitest adicional
- Qué testear con E2E: flujos críticos de negocio (auth, checkout, forms multi-step), navegación entre páginas, uploads y descargas — lo que no se puede testear de otra forma
- Qué NO testear con E2E: casos edge (unit), lógica interna de componentes (integration), estilos y variantes visuales (visual regression) — la decisión que más tiempo ahorra
Fuentes de referencia
Docs
Playwright — Documentation
playwright.dev/docs/intro — Documentación oficial de Playwright con guías por framework (Angular, React, Next.js) y por caso de uso (auth, API testing, mobile).
Abrir →YouTube
Playwright — Canal oficial
Ejemplos de multi-browser, CI con sharding y locators modernos. El contenido más actualizado sobre las últimas features de Playwright.
YouTube
Jack Herrington — Playwright vs Cypress
Comparación técnica honesta para decidir cuál adoptar. Trade-offs reales de DX, velocidad en CI y compatibilidad por framework.
Tool
@playwright/test
npmjs.com/@playwright/test — El test runner integrado de Playwright con fixtures, paralelismo, sharding y reporting HTML incluidos sin configuración adicional.
Abrir →Contenido de la semana
- Por qué testear accesibilidad: el mismo código accesible es más fácil de testear — la sinergia entre a11y y testing hace que ambas prácticas se refuercen
- vitest-axe / jest-axe: integración de axe-core con Vitest/Jest — toHaveNoViolations como assertion automático de WCAG 2.1 sin esfuerzo adicional
- Queries semánticas como tests de a11y: getByRole("button", {name: /submit/i}) valida que el botón tiene nombre accesible — query y a11y check en uno
- Roles ARIA en RTL: button, checkbox, combobox, dialog, heading, listitem, menu, tab, textbox — la tabla completa y cómo name, level e hidden los filtran
- Testing con teclado: userEvent.tab() para navegar, userEvent.keyboard("{Enter}") para activar — verificar que forms y modals funcionan sin mouse
- Limitaciones del testing automático: axe detecta ~30% de los problemas de a11y — testing manual con lectores de pantalla (NVDA, VoiceOver) como complemento indispensable
Fuentes de referencia
Tool
vitest-axe
github.com/nickvdyck/vitest-axe — La versión de jest-axe adaptada para Vitest. Setup en 5 líneas, toHaveNoViolations como matcher y reporte detallado de violaciones.
Abrir →Docs
Testing Library — getByRole
testing-library.com/docs/queries/byrole — Referencia completa de getByRole con todos los roles ARIA, las opciones name/level/hidden y ejemplos de cada uno.
Abrir →YouTube
Marcy Sutton — Accessibility Testing with Jest and Axe
La experta en a11y más reconocida del ecosistema. Explica qué detecta axe, qué no detecta y cómo combinar testing automático con manual.
Tool
axe-core
github.com/dequelabs/axe-core — La base de todas las herramientas de testing automático de accesibilidad. También disponible como extensión de browser para inspección manual.
Abrir →Contenido de la semana
- Visual Regression Testing: detectar cambios visuales no intencionales entre builds — snapshots de pantalla completa o de componentes aislados comparados automáticamente
- Storybook + Chromatic: cada story es un test visual — Chromatic captura screenshots por story y detecta diffs pixel a pixel automáticamente en cada PR
- Percy como alternativa: integrado con Cypress y Playwright — screenshots en el browser real durante los E2E tests existentes sin tests adicionales
- Coverage con Istanbul/V8: líneas (lines), ramas (branches), funciones (functions), sentencias (statements) — por qué branches es la métrica más reveladora
- Thresholds de coverage en vitest.config.ts: cuándo 80% es un objetivo razonable y por qué 100% genera tests vacíos que solo aumentan el número
- Coverage como guía, no como meta: un test malo que ejecuta código no mejora la calidad — coverage mide ejecución, no corrección del comportamiento
Fuentes de referencia
Docs
Storybook — Visual Testing
storybook.js.org/docs/writing-tests/visual-testing — Guía oficial de visual testing con Storybook y Chromatic. Cómo configurar el workflow y qué historias testear.
Abrir →Docs
Vitest — Coverage
vitest.dev/guide/coverage — Configuración de coverage en Vitest: V8 vs Istanbul, thresholds por tipo, reporters HTML e integración con Codecov.
Abrir →YouTube
Storybook — Visual Testing with Chromatic
Demo completo del workflow de visual regression: commit → Chromatic detecta diff → PR review → aprobación. El ciclo completo en 15 minutos.
Tool
chromatic
chromatic.com — La plataforma de visual testing más integrada con el ecosistema Storybook. Plan gratuito con 5000 snapshots/mes para proyectos personales.
Abrir →Contenido de la semana
- El ciclo Red → Green → Refactor en la práctica: escribir el test mínimo que falle (rojo), el código mínimo que lo pase (verde), refactorizar con red de seguridad activa
- Baby Steps: por qué los pasos más pequeños posibles producen el mejor diseño emergente — la disciplina más difícil del TDD y la que más impacto tiene
- TDD sobre funciones puras: el lugar ideal para empezar — input/output sin side effects, feedback en milisegundos, sin mocks, sin async
- Triangulación: escribir un segundo test para forzar una generalización — cómo evitar hardcodear la solución mínima que solo pasa el primer test
- TDD como diseño: el código escrito con TDD tiende a ser más modular, con menor acoplamiento, con interfaces más limpias — el beneficio real no es "cero bugs"
- Katas para internalizar el ritmo: FizzBuzz (empezar aquí), String Calculator, Bowling Game — repetición deliberada del ciclo hasta que sea reflejo
Fuentes de referencia
Libro
Test-Driven Development: By Example
Kent Beck. El libro original de TDD. Leer el Money Example en la Parte I — 16 capítulos cortos que muestran el ciclo completo con Baby Steps reales. La experiencia de leer a Beck haciendo TDD es irreemplazable.
Libro
The Art of Unit Testing
Osherove. Cap 5-6: Mocking frameworks e isolation en el contexto de TDD — cuándo los mocks son necesarios en el ciclo Red/Green/Refactor y cuándo dificultan el diseño.
YouTube
David Farley — Test-Driven Development
La serie más técnica y profunda de TDD en YouTube. David Farley es el co-autor de Continuous Delivery — su perspectiva es la del ciclo completo de delivery, no solo del test.
Katas
kata-log.rocks
kata-log.rocks — Catálogo de katas organizadas por dificultad y por concepto. Empezar por FizzBuzz, luego String Calculator, luego Bowling Game.
Abrir →Contenido de la semana
- Outside-In TDD (London School): empezar por el comportamiento observable del exterior, mockear colaboradores y dejar que los tests definan el contrato de cada pieza
- Outside-In vs Inside-Out (Chicago School): descubrimiento emergente vs diseño previo — cuándo cada enfoque tiene ventaja y por qué la mayoría de los devs mezcla los dos
- TDD en componentes Angular: escribir el test de integración del componente primero, luego extraer servicios y escribir sus unit tests — diseño guiado por uso real
- Contract Testing con Pact: el consumidor define el contrato (mock + expectativas de la respuesta), el proveedor lo verifica contra su implementación real
- Consumer-Driven Contract Tests: el frontend lidera el contrato de la API — permite que frontend y backend se desplieguen de forma independiente con garantías
- Schema Validation con Zod como alternativa light: validar respuestas de API en runtime cuando Pact es demasiado para el tamaño del equipo
Fuentes de referencia
Libro
Growing Object-Oriented Software, Guided by Tests
Freeman & Pryce. El libro de Outside-In TDD. Leer los capítulos 1-4 esta semana — el Walking Skeleton en el capítulo 2 es el concepto central del Outside-In.
Docs
Pact — JavaScript Documentation
docs.pact.io — Documentación oficial de Pact para JavaScript. Setup consumer + provider con ejemplos de API REST y la integración con el Pact Broker.
Abrir →YouTube
Dave Farley — Outside-In TDD
Explica el London School vs Chicago School con código real y trade-offs honestos. El video que más claridad da sobre cuándo cada enfoque tiene sentido.
Tool
@pact-foundation/pact
npmjs.com/@pact-foundation/pact — La implementación de Pact para JavaScript/TypeScript. Consumer DSL para definir el contrato y verifier para validarlo contra el provider.
Abrir →Contenido de la semana
- GitHub Actions para tests: workflow YAML con triggers en push y pull_request, steps de install → test → coverage, artifacts para guardar el reporte HTML
- Bloquear merge con Branch Protection Rules: required status checks configurados en el repo — el único mecanismo que garantiza que nadie saltea los tests en un PR
- Paralelización en CI: matrix strategy para multi-node, Playwright --shard para distribuir E2E, Cypress parallelization — reducir el tiempo de feedback de 10min a 2min
- Gates de cobertura: coverage thresholds que fallan el pipeline si bajan del umbral — cuándo configurarlos y cuándo son contraproducentes para el equipo
- Cache de dependencias en CI: actions/cache para node_modules — el cambio de configuración que más tiempo ahorra en pipelines con muchas dependencias
- Reporte de resultados: JUnit XML reporter para GitHub Actions, PR comments con coverage diff via Codecov, Coveralls como alternativa gratuita
Fuentes de referencia
Docs
GitHub Actions — Documentation
docs.github.com/actions — Guía oficial de GitHub Actions con ejemplos para Node.js, matrix strategy, cache de dependencias y secrets. La fuente de verdad.
Abrir →Docs
Playwright — CI GitHub Actions
playwright.dev/docs/ci-github — Configuración oficial de Playwright en GitHub Actions con sharding, artifacts de videos y screenshots, y reportes de HTML.
Abrir →YouTube
Fireship — GitHub Actions Tutorial
El más conciso para entender GitHub Actions en 10 minutos. Cubre triggers, steps, secrets y el workflow de CI básico para un proyecto frontend.
Tool
actions/cache
github.com/actions/cache — Cachear node_modules en CI es la primera optimización que siempre vale la pena. Configurable con una clave basada en el hash de package-lock.json.
Abrir →03 — Biblioteca de referencia
Libros recomendados
Los libros que forman la base mental de un buen tester.
Unit Testing: Principles, Practices and Patterns
Recurso principal W01–W09El mejor libro moderno sobre unit testing. Empieza con "qué queremos lograr" antes de enseñar herramientas. La distinción entre mocks y stubs del capítulo 5 es la más clara disponible.
The Art of Unit Testing
Fases 1-2 · W01–W04El libro de referencia para aprender unit testing desde cero. La 3ª edición (2023) incorpora JavaScript y TypeScript. El más accesible para empezar antes de Khorikov.
Test-Driven Development: By Example
Fase 4 · TDD W14El clásico fundacional de TDD. El Money Example en la Parte I muestra el ciclo Red/Green/Refactor con Baby Steps reales. Leer a Beck haciendo TDD es una experiencia irreemplazable.
Growing Object-Oriented Software, Guided by Tests
Fase 4 · TDD Avanzado W15Outside-In TDD (London School) llevado a la práctica. El Walking Skeleton del capítulo 2 es el concepto central. Leer después de Kent Beck — requiere el ciclo básico interiorizado.
04 — Timeline visual
