Del Page Object hecho a mano al framework profesional.
Hoy no aprendes piezas nuevas — aprendes el mapa que las ensambla.
Última sesión de la serie Código al Grano. Tono distinto: ya no enseñas a programar — revelas que el framework "intimidante" está hecho 100% de piezas que ellos ya construyeron a mano. Prerrequisito: serie completa (especialmente Coding Classes y Playwright Pro). Duración: 90 min + exploración del repo real.
Hace 5 sesiones, "Ana" era tu primer valor. Hoy tienes: suite multi-browser con Page Objects y fixtures propios, publicada en GitHub por PR. Lo que falta no es conocimiento — es el mapa del territorio profesional.
Momento de perspectiva: recorre la línea y deja que dimensionen el progreso (de un string suelto a un mini-framework publicado). Define la sesión: "hoy no hay sintaxis nueva — hay un MAPA". Eso relaja: el esfuerzo cognitivo de hoy es de reconocimiento, no de aprendizaje desde cero.
pages/ + fixtures.ts + tests/. Funciona hermoso. Pero ahora imagina:
📈 40 páginas y 30 endpoints de API
👥 5 QAs escribiendo a la vez
🌍 3 ambientes (local, staging, prod)
🎲 datos fake distintos en cada corrida
🔍 trazabilidad: cada test ↔ su test case del TMS
Cada POM repite los mismos helpers (waits, navegación, formularios) → capa de bases heredables.
Credenciales y URLs hardcodeadas por ambiente → capa de configuración.
Con 5 QAs, nadie sabe qué ya existe → duplicados → un registro central.
Cada dolor de escala tiene una pieza con nombre. Eso ES el framework.
La motivación de toda arquitectura: los dolores de escala. Cada dolor de la derecha mapea a una pieza KATA que viene en las siguientes slides (bases→L2, config→L1, registro→manifest). Presenta KATA como RESPUESTA a problemas que ellos ya rozaron, no como dogma.
KATA como en artes marciales: una forma ensayada hasta que sale sola. Dos mecanismos que ya dominas la sostienen: extends (Coding Classes) y fixtures (Playwright Pro). Nada más.
LA slide de la sesión — el mapa al que volverás en cada capa. Punto clave: solo hay DOS mecanismos (herencia y fixtures) y ambos los dominan. La estrella verde en L3 delimita su territorio: las otras capas se HEREDAN o se RECIBEN, no se tocan en el trabajo diario. Las siguientes 3 slides recorren las capas de abajo... de arriba hacia abajo.
• Config por ambiente: URLs y credenciales salen de .env + config — mata tus credenciales hardcodeadas
• Faker: datos fake frescos en cada corrida (¿recuerdas tu Date.now() del email único? esto, industrializado)
• Utilidades agnósticas compartidas por API y UI
• UiBase: navegación, waits inteligentes, helpers de formularios — todo lo que tus POMs repetían
• ApiBase: cliente HTTP con auth, headers y manejo de errores resuelto
// Tu LoginPage de Playwright Pro: export class LoginPage { // extendía... nada // goto, waits, helpers: a mano 😅 } // En KATA: export class LoginPage extends UiBase { // hereda navegación, waits, forms, // config y faker — GRATIS 🎁 // tú solo escribes lo específico de login }
La cadena extends que practicaste con User → Admin, pagando su dividendo más grande: escribes solo lo que es único de tu página.
L1 y L2 juntas = "lo que heredas gratis". Conexiones directas: credenciales hardcodeadas (dolor que ellos tienen) → TestContext; el Date.now() del lab → faker; sus helpers repetidos → UiBase. El código de la derecha es el antes/después que resume la sesión: extends convirtiendo trabajo repetido en herencia.
export class LoginPage extends UiBase { /** @atc TC-101 — login con credenciales válidas */ async loginAs(user: { email: string; password: string }) { await this.page.goto(this.config.webUrl + "/login"); await this.page.getByLabel("Email").fill(user.email); await this.page.getByLabel("Password").fill(user.password); await this.page.getByRole("button", { name: /sign in/i }).click(); } }
Acceptance Test Case: un método que ejecuta un mini-flujo completo y atómico. Tu login() de siempre — con identidad y reglas.
Cada ATC lleva el ID de su test case del TMS — trazabilidad: del código al test documentado y de vuelta.
Nota la firma: loginAs(user) recibe un objeto — regla de la casa para 3+ datos.
ATC = el corazón conceptual de KATA. Es su método login() de toda la serie, elevado: identidad (TC id → trazabilidad con el TMS), atomicidad (regla de la próxima slide) y convención de firma. El this.config.webUrl muestra a TestContext en acción: cero URLs hardcodeadas. El término "atómico" se define formalmente en la siguiente slide — aquí basta "completo e independiente".
| Regla | Qué significa | Por qué |
|---|---|---|
| Atómico | Un ATC ejecuta UN mini-flujo completo y NUNCA llama a otro ATC | Si A llama a B y B cambia, A se rompe en cadena — el dominó que mata frameworks |
| Cadenas → Steps | ¿Necesitas login + crear proyecto + invitar? Eso es un Steps module que orquesta ATCs | Composición explícita en un solo lugar, no acoplamiento oculto |
| Locators inline | Los locators viven DENTRO del ATC; se extraen solo si 2+ ATCs los usan | Leer un ATC = verlo completo, sin saltar entre archivos |
| Máx 2 params sueltos | 3 o más datos → un objeto: loginAs({ email, password, role }) | fn(a, b, c, d) = ¿cuál era el tercero? El objeto se autodocumenta |
Las 4 reglas que difieren de lo que harían por instinto. La #1 es LA regla: ATCs no se llaman entre sí — el dominó de dependencias es la muerte lenta de los frameworks caseros. Steps existe precisamente para componer sin acoplar. Locators inline sorprende a quien aprendió "extraer todo" — KATA prefiere legibilidad local; la extracción se GANA con el segundo uso.
createProject() necesita que el usuario esté logueado. ¿Puede llamar internamente a loginAs()?El quiz más importante del deck — la opción A es exactamente lo que su instinto (bien entrenado en reutilización) les dicta. La distinción fina: reutilizar ≠ acoplar ocultamente. Composición explícita (Steps, fixtures) vs llamadas internas invisibles. Quien entiende esto ya piensa en arquitectura.
// Tu spec en KATA: import { test, expect } from "@fixtures/test.fixture"; test("crear proyecto", async ({ ui }) => { await ui.loginPage.loginAs(ui.ctx.users.admin); await ui.projectsPage.createProject({ name: "Demo" }); await expect(ui.page.getByText("Demo")).toBeVisible(); });
ui llega con TODAS las páginas instanciadas + contexto + datos. Cero new, cero setup — como tu fixture loginPage, multiplicado.
| Test solo de API | ({ api }) — sin browser, vuela |
| Test solo de UI | ({ ui }) — páginas listas |
| Híbrido (API prepara, UI verifica) | ({ test }) — ambos mundos |
Pedir { api } en un test de API no levanta navegador — tu suite de 200 tests de API corre en segundos. El fixture correcto = la velocidad correcta.
L4 cierra el círculo de fixtures iniciado en Playwright Pro. La regla de selección es práctica diaria: el error común es pedir {test} para todo "por si acaso" — pagando browser en tests que no lo usan. El spec de ejemplo se lee como historia: ese es el premio de toda la arquitectura.
Quiz de hábito profesional: fixture mínimo necesario. Conecta con la pirámide (API rápida) — la arquitectura premia con velocidad a quien elige bien. En el repo real, elegir mal el fixture es de lo primero que se marca en code review.
// kata-manifest.json (extracto) { "components": { "LoginPage": { "file": "tests/components/pages/login.page.ts", "atcs": ["TC-101", "TC-102"] }, "AuthApi": { "file": "tests/components/api/auth.api.ts", "atcs": ["TC-201"] } } }
"¿Ya existe un ATC de login?" — el manifest responde en 2 segundos. Se consulta SIEMPRE antes de crear un Component o ATC nuevo. Anti-duplicación.
bun run kata:manifest lo regenera leyendo el código. Nunca a mano.
Manifest desactualizado = el commit se bloquea (hook de pre-commit). El registro nunca miente porque no puede quedarse atrás.
El manifest resuelve el dolor de los 5 QAs: registro central consultable. Dos hábitos: consultarlo ANTES de crear (anti-duplicación) y regenerarlo tras crear (bun run kata:manifest). El pre-commit hook conecta con su conocimiento de git de Dev Craft: git ejecuta validaciones antes de aceptar el commit — el framework se protege solo.
¿Recuerdas /api/docs del dojo? Aquí el contrato OpenAPI se convierte en tipos TypeScript: tu test de API sabe la forma exacta de cada respuesta. Typo en un campo = error antes de ejecutar.
Mapas del negocio bajo prueba: features, datos, APIs, plan maestro. La "memoria" del proyecto — tuya y de la IA.
bun install = npm install · bun run test = npm run test. Mismo concepto, motor más rápido.
Vista de dron, no tour exhaustivo. api/schemas conecta con su experiencia de /api/docs: contrato → tipos → shift-left en tests de API. .context/ prepara la mentalidad agentic de la siguiente slide: el repo guarda contexto para humanos E IA. bun: una línea basta, ya conocen el concepto de package manager.
Trae flujos guiados por IA: /sprint-testing (QA manual de tickets), /test-automation (escribir tests KATA), /regression-testing (suites en CI). La IA conoce las reglas KATA y consulta el manifest.
Regla de la casa: plan de implementación ANTES de escribir código. La IA propone el plan, tú lo apruebas, luego se escribe. Nada de código a ciegas.
Porque tu rol NO es tipear código — es tener criterio:
✅ Leer lo que la IA propone y detectar lo que está mal
✅ Juzgar: ¿este ATC es atómico? ¿el fixture es el mínimo? ¿el locator sobrevivirá?
✅ Decidir qué se prueba, qué se automatiza y qué NO
Sin las 6 sesiones, la IA te dicta. Con ellas, tú diriges.
La slide que recontextualiza la serie completa: aprendieron a programar no para tipear más rápido que una IA (imposible) sino para REVISAR con criterio (irreemplazable). El QA Engineer moderno dirige agentes: aprueba planes, revisa diffs, impone las reglas. Todo el viaje fue entrenamiento de criterio — este es el mensaje más importante del deck para su carrera.
registerUser(name, email, password, role). ¿Qué marcas en el review?Ensayo del rol real: review de código generado por IA. La opción A es la trampa de la complacencia ("pasa, aprobado") — el estándar profesional es reglas + criterio, no solo verde. Señala el patrón de la C: arreglos que rompen funcionalidad para cumplir una regla — el criterio también protege contra eso.
1. Clona (la URL te la da tu lead):
2. El ritual del clon (¡quiz 1 de Dev Craft!), versión bun:
3. Abre y explora:
Encuentra y abre estos 4 lugares:
tests/components/ ¿ves bases y pages?
kata-manifest.json ¿cuántos components hay?
api/schemas/ ¿reconoces tipos TS?
package.json ¿qué scripts ofrece?
macOS/Linux: curl -fsSL https://bun.sh/install | bash · Windows: powershell -c "irm bun.sh/install.ps1 | iex" — luego reabre la terminal.
bun install sin errores, y encontraste los 4 lugares del mapa.Primera vez pisando el repo real — toda la sesión fue preparación para este momento. La búsqueda de los 4 lugares convierte el mapa conceptual en territorio físico. Ten la URL del repo lista para compartir. Si bun falta, la pista instala — 1 minuto.
1. Abre kata-manifest.json
2. Elige un Component que te llame la atención
3. Salta a su archivo (el manifest te da la ruta)
4. Lee UN ATC completo, línea por línea
5. Verifica las reglas: ¿es atómico? ¿locators inline? ¿firma con objeto si 3+ datos?
Apunta QUÉ exactamente. Si es sintaxis TS avanzada (generics, decorators) — normal, se aprende en el camino. Si es estructura (¿de dónde sale this.config?) — sigue la cadena extends hacia arriba: la respuesta vive en UiBase o TestContext. Saber RASTREAR la herencia es la habilidad.
Meta honesta: deberías reconocer el 80%+ de cada ATC (clase, this, async/await, locators, params). El 20% restante es lo que el trabajo diario te dará.
La misión espejo de toda la serie: leer código de producción real y reconocer el 80%. El criterio de éxito (explicar a otro) es la prueba de comprensión definitiva — en grupo, haz que algunas personas lo hagan en voz alta. La pista enseña a rastrear herencia: la habilidad de lectura de frameworks.
1. Abre cualquier spec de tests/e2e/
2. Por cada elemento, anota de qué deck salió:
import { test } from "@fixtures/..." | → ¿deck? |
async ({ ui }) => | → ¿deck? |
ui.loginPage.loginAs({...}) | → ¿deck? |
await expect(...).toBeVisible() | → ¿deck? |
Si completas la tabla sin ayuda, estás graduada/o: no queda UNA sola línea de un spec profesional que no puedas explicar. El framework dejó de ser una caja negra.
import/módulos → Coding Base + Pro · arrow + destructuring → Coding Classes · ATC sobre Page heredada → Classes + Pro + hoy · expect web-first → Dojo Lab + Pro. Todo el viaje, en 10 líneas de spec.
La misión de graduación es metacognitiva: demostrar que el spec profesional es 100% trazable a lo aprendido. Cierra el arco abierto en la slide 2 de Coding Base ("ya sabes programar, solo que en papel"). Celebra en grande a quien complete la tabla sin mirar las respuestas.
Último quiz de la serie y resume el cambio de mentalidad completo: de "persona que escribe código" a "ingeniera/o que construye sobre un sistema compartido". El orden manifest → plan → código es literalmente el flujo de /test-automation del repo. Con esto están listos para su primer ticket real.
| Lo aprendiste como… | En KATA se llama… | Deck |
|---|---|---|
Clase con métodos (LoginPage) | Component de capa L3 | Coding Classes |
Método login() del POM | ATC con ID de trazabilidad | Classes + Pro |
extends + super | La columna vertebral: L1 → L2 → L3 | Coding Classes |
Tu fixtures.ts con ({ loginPage }) | TestFixture L4: ({ ui }), ({ api }) | Playwright Pro |
| Helpers que repetías en cada POM | UiBase / ApiBase (L2) — heredados | Pro + hoy |
| Credenciales hardcodeadas 😅 | TestContext (L1) — config por ambiente | hoy |
Date.now() para emails únicos | Faker en TestContext | Dojo Lab |
Tu rama test/* + PR | El flujo de entrega del repo (idéntico) | Dev Craft |
La tabla-diccionario es el regalo de despedida: imprimible, consultable, y demuestra que NADA de KATA salió de la nada. Recórrela rápido — cada fila es un "ya lo sabes". Es también tu herramienta de onboarding para futuros cohorts.
Pide el tour guiado: /agentic-qa-onboard en el repo te explica el flujo completo de QA (con visuales como estos).
Un ticket real con /test-automation: la IA propone el plan, TÚ lo revisas con todo tu criterio nuevo, y juntos escriben el ATC.
Rama test/*, commits semánticos, PR con review — el flujo de Dev Craft, ahora en el repo del equipo.
El dojo no se va: nuevos specs, nuevos POMs, nuevos retos. Los 6 decks quedan contigo para repasar.
El músculo de criterio crece revisando PRs ajenos. Ofrécete de reviewer desde la semana 1.
KATA = forma ensayada hasta que sale sola. La primera semana se siente torpe. La cuarta, natural. La octava... lo enseñas tú.
Aterrizaje concreto: 3 pasos secuenciados para la primera semana + 3 hábitos de crecimiento. El paso 2 define la dinámica agentic real desde el día uno: IA propone, humano dirige. Cierra con la card del kata: la torpeza inicial es parte del diseño del aprendizaje.
Un valor → una variable → una función → una clase → un Page Object → fixtures → git → un framework profesional que ahora sabes leer, juzgar y dirigir.
Bienvenida/o al oficio. Nos vemos en el repo. 🥋
Cierre de la serie completa — 6 decks, un arco. Lee el viaje en voz alta de principio a fin: desde "Ana" en la slide 4 del primer deck hasta dirigir una IA en un framework profesional. Celebra, recoge feedback de la serie y agenda el onboarding del repo + primer ticket. El confetti final es automático al llegar aquí. Esto fue Código al Grano.