Del Page Object hecho a mano al framework profesional.
Aquí no aprendes piezas nuevas — aprendes el mapa que las ensambla.
Sesión 6 de la serie Código al Grano y cierre de los fundamentos; después siguen Automation Patterns y API Automation (ver el catálogo). 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: los decks anteriores del catálogo (especialmente Coding Classes y Playwright Pro). Duración: 90 min + exploración del repo real.
Al inicio de la serie, "Ana" era tu primer valor. Ahora 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: "en esta sesión no hay sintaxis nueva — hay un MAPA". Eso relaja: el esfuerzo cognitivo de esta sesión 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
• DataFactory (faker por dentro): datos frescos en cada corrida (recuerdas tu Date.now() del email único? esto, industrializado)
• Los drivers de Playwright (page, request) y el entorno, compartidos por API y UI
• UiBase: buildUrl, interceptar respuestas y esperar llamadas de red — lo que tus POMs repetían. Los helpers de formulario viven en cada componente
• 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 buildUrl, waits de red, // config y datos — 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 → DataFactory; 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 { @step async goto() { await this.page.goto(this.buildUrl("/login")); } // login con credenciales válidas @atc('PROJ-111') async loginSuccessfully(credentials: LoginCredentials) { await this.fillAndSubmitLoginForm(credentials); await expect(this.page).not.toHaveURL(/.*\/login.*/); } }
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 la clave Jira literal del ticket que cubre: trazabilidad: del código al test documentado y de vuelta. Nunca un id sintético ni un template literal.
Nota la firma: loginSuccessfully(credentials) recibe un objeto { email, password }, y con 3+ datos es regla de la casa.
ATC = el corazón conceptual de KATA. El ATC ES el caso de prueba; @atc('PROJ-111') es su representación en código. Es su método login() de toda la serie, elevado: identidad (clave Jira → trazabilidad con el TMS), atomicidad (regla de la próxima slide) y convención de firma. El this.buildUrl("/login") muestra la cadena en acción: UiBase arma la URL con config.baseUrl, que viene de TestContext. 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: loginSuccessfully({ 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 loginSuccessfully()?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 "@TestFixture"; test("crear proyecto", async ({ ui }) => { await ui.login.goto(); await ui.login.loginSuccessfully({ email, password }); await ui.projects.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.
Ojo con las aserciones. En POM aprendiste "acciones en la página, aserciones en el test". KATA lo matiza: las aserciones fijas — status code, campos requeridos, redirect — viven dentro del ATC, porque son parte de su contrato. Solo las aserciones de flujo, las que dependen del escenario, van en el spec.
| 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, campos recortados) { "components": { "api": [{ "name": "AuthApi", "relativePath": "tests/components/api/AuthApi.ts", "atcs": [{ "id": "PROJ-101", "method": "authenticateSuccessfully" }, …] }], "ui": [{ "name": "LoginPage", "relativePath": "tests/components/ui/LoginPage.ts", "atcs": [{ "id": "PROJ-111", "method": "loginSuccessfully" }, …] }] } }
"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.
Los mapas del negocio bajo prueba (dominio, datos, APIs, journeys) viven como HTML dentro de sus context skills en .agents/skills/ y se leen con bun run context:map <slug>. El plan maestro vive en Jira (epic QA Master Test Plan). .context/ guarda la cache de Jira y las decisiones (ADRs). 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. Los context skills y .context/ preparan 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), entre otros: ver .agents/skills/REGISTRY.md. 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 la serie, 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 "@TestFixture" | → deck? |
async ({ ui }) => | → deck? |
ui.login.loginSuccessfully({...}) | → 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 + esta sesión · 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 «Ya sabes programar. Solo que en papel» 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 + esta sesión |
| Credenciales hardcodeadas 😅 | TestContext (L1) — config por ambiente | esta sesión |
Date.now() para emails únicos | DataFactory (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 decks de la serie 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. 🥋
Sigue en el catálogo: Automation Patterns y API Automation con Playwright.
Cierre de los fundamentos, un arco. Lee el viaje en voz alta de principio a fin: desde "Ana" en el 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.