Tu suite vive solo en tu laptop — para el equipo, no existe.
Hoy: terminal con soltura, Git sin miedo y tu primer Pull Request.
Sesión 6 de la serie (deck 5). El gap silencioso: saben escribir tests pero no compartirlos como profesionales. Hoy hay 2 terminales SIMULADAS dentro del deck (practican git sin riesgo) + misiones reales sobre su proyecto del lab. Prerrequisito: proyecto mi-dojo-lab funcionando. Duración: 90-120 min.
Laptop muere = suite muere. "¿Qué cambié ayer?" = misterio. Dos personas editando = caos de versiones por email.
Tu suite entra al repo del equipo por Pull Request, con revisión, igual que el código de los devs. Mismo flujo, mismos estándares.
Acto 1 → terminal sin miedo
Acto 2 → package.json y scripts
Acto 3 → Git local 🎮 (simulador + real)
Acto 4 → GitHub + tu primer PR 🎮
Boss → tu suite del lab, publicada
Hoy estrenamos terminales simuladas dentro del deck: practicas los comandos aquí (imposible romper nada) y DESPUÉS los corres de verdad.
Motivación con dolor real: pregunta quién ha perdido trabajo por no tener respaldo. El paralelo de identidad importa: entregar por PR es lo que distingue al QA Engineer del tester que automatiza por su cuenta — entras al flujo de ingeniería del equipo. El simulador baja la ansiedad de los que le temen a la terminal.
| Comando | Qué hace | Mnemonia |
|---|---|---|
pwd | ¿DÓNDE estoy parado? | print working directory |
ls | ¿QUÉ hay aquí? | list |
cd mi-dojo-lab | Entra a una carpeta | change directory |
cd .. | Sube un nivel | .. = la carpeta padre |
mkdir pages | Crea una carpeta | make directory |
code . | Abre VS Code AQUÍ | . = esta carpeta |
Los dos superpoderes: Tab autocompleta nombres (escribe cd mi-d + Tab) · flecha ↑ repite comandos anteriores. Quien los usa parece senior en una semana.
Desmitificación: 6 comandos cubren el 90% del día a día. El concepto subyacente: la terminal SIEMPRE está parada en una carpeta (pwd lo revela) y todo es relativo a ella — el mismo concepto de las rutas relativas de los imports (../pages). Tab y ↑ son los hábitos que más aceleran a un principiante.
1. Abre una terminal nueva (no la de VS Code — esa hace trampa)
2. pwd para ubicarte, ls para mirar
3. Navega con cd + Tab hasta mi-dojo-lab
4. Remata con:
Abre VS Code → Cmd+Shift+P → escribe "shell command" → "Install 'code' command in PATH". Reabre la terminal.
cd ~ te teletransporta a tu carpeta de usuario (home). Desde ahí, ls y a navegar de nuevo. Imposible perderse para siempre.
Misión corta (5-10 min) pero diagnóstica: quien no fluye aquí va a sufrir con git. "Terminal nueva, no la de VS Code" fuerza la navegación real. cd ~ como botón de pánico elimina el miedo a perderse.
{
"name": "mi-dojo-lab",
"scripts": {
"test": "playwright test",
"test:ui": "playwright test --ui"
},
"devDependencies": {
"@playwright/test": "^1.52.0"
}
}
Identidad del proyecto.
El recetario de comandos del equipo: alias cortos para comandos largos. Se corren con npm run <nombre>.
La lista de compras: qué herramientas necesita el proyecto y en qué versión. npm install las trae todas.
Pesa cientos de MB y se reconstruye desde la lista con npm install. Por eso JAMÁS se sube a Git (lo ignoraremos en el Acto 3).
La metáfora doble: scripts = recetario, dependencies = lista de compras, node_modules = la despensa llena (reconstruible, no se comparte). Esta lógica explica el ritual universal "clonar → npm install" y prepara el .gitignore del acto 3. dependencies vs devDependencies: para un proyecto de tests, todo es dev — no profundices.
1. En tu package.json, dentro de "scripts":
"test": "playwright test", "test:ui": "playwright test --ui", "test:headed": "playwright test --headed", "report": "playwright show-report"
2. Pruébalos:
JSON es estricto: comillas dobles SIEMPRE, coma entre entradas, ninguna coma después de la última. VS Code subraya el error exacto.
El valor real: contrato de equipo. Cualquier persona (o un pipeline de CI) corre tu suite con npm run test sin saber qué hay detrás. Estándar universal del ecosistema.
npm run test y npm run test:ui funcionan en tu proyecto.Primera edición a mano de un JSON — el error de sintaxis de la pista le pasará a alguien, garantizado, y es buena lección (JSON estricto vs JS laxo). El concepto "contrato de equipo" conecta con CI/CD futuro: los pipelines corren npm run test, no comandos crudos.
npm run test y explota: "Cannot find module '@playwright/test'". ¿Primer comando?npm install lee las dependencies del package.json y la reconstruye exacta. El ritual universal: clonar → npm install → a trabajar. La opción C funciona… como funciona pegar un billete roto con cinta: no lo hagas.Este error lo VAN a vivir la primera vez que clonen algo — el quiz lo convierte en momento "ya sabía". El ritual clonar → npm install → npx playwright install (browsers) completo lo verán en la misión boss cuando clonen su propio repo si hay tiempo.
Commit = grabar partida. ¿Rompiste todo? Vuelves al último checkpoint. Nada se pierde de verdad después de un commit.
Eliges QUÉ entra en cada foto. Cambiaste 5 archivos pero 2 son de otra tarea → fotos separadas, historia limpia.
Te dice qué está modificado, qué está en staging y qué falta. Cuando dudes: git status. Siempre.
El modelo de 3 zonas ES git — todo comando se entiende desde aquí. Insiste en "git status como brújula": el hábito que salva a todo principiante (no castiga, solo informa). La metáfora checkpoint de videojuego baja el miedo: con commits frecuentes, nada se pierde.
git add . = todo lo modificado al staging · -m = mensaje inline.
Antes del primer commit: crea .gitignore con node_modules/, test-results/ y playwright-report/ — la despensa y los reportes NO van en la historia.
| ❌ Indigno | ✅ Digno |
|---|---|
| "cambios" | "add login page object with semantic locators" |
| "fix" | "fix flaky register test with unique email" |
| "asdfgh" | "add API tests for auth endpoints" |
Fórmula: verbo + qué + (por qué si no es obvio). El humano del futuro que lee tu historia… casi siempre eres tú.
El .gitignore ANTES del primer commit es crítico — commitear node_modules es el error #1 de novato (repo de 500MB). Mensajes: la prueba está en git log — una historia de "cambios, fix, más cambios" no le sirve a nadie. Convención del repo profesional al que van: prefijos semánticos (feat:, fix:, test:) — menciónalo como adelanto.
Primer simulador: el ciclo status → add → commit → log en un sandbox. Pide que NO miren la slide anterior — que recuerden el ciclo (la lista de objetivos a la izquierda guía). Tras completarlo aquí, la misión D3 lo repite en su proyecto real. La opción "help" lista comandos si se traban.
Crea .gitignore (raíz del proyecto) con:
node_modules/ test-results/ playwright-report/
Primera vez con git en esta máquina:
git config --global user.name "Tu Nombre" git config --global user.email "tu@email.com"
Una sola vez, queda configurado para siempre.
git status ANTES del add: si node_modules aparece en la lista, el .gitignore tiene un typo o está en la carpeta equivocada.
git log --oneline muestra tu commit inicial, y git status NO lista node_modules.Del sandbox a la realidad. El config de identidad detendrá a la mayoría (primera vez con git) — la pista lo resuelve. Verificación del gitignore vía git status: hábito de comprobar, no asumir. Si alguien ya commiteó node_modules: borra .git completo y reinicia la misión — más simple que enseñar a deshacer hoy.
git add acepta archivos específicos — esa es la razón de ser del staging: componer CADA foto deliberadamente. git add . es el atajo para "todo", no la única forma. Historia limpia = un commit por intención = futuro tú feliz.Valida el modelo de 3 zonas con el caso de uso que justifica el staging. La opción C (borrar y recrear) suena absurda pero es lo que hace la gente que no entiende staging — nómbralo con humor. Commits por intención preparan el terreno para PRs enfocados.
Remoto = el repo "oficial" compartido. push sube tus commits; pull baja los de otros. Laptop muere → la historia vive.
Con GitHub CLI (recomendado — crea el repo Y lo conecta):
github.com → New repository → copia los comandos que GitHub te muestra bajo "push an existing repository": git remote add origin … + git push -u origin main.
Modelo simple: local = tu copia, remoto = la oficial compartida. gh CLI hace en 1 comando lo que la web hace en 5 pasos — pero requiere gh instalado (brew install gh / winget install GitHub.cli); la alternativa web siempre funciona. gh auth login es interactivo: guíalo en vivo.
Nadie empuja directo a main: es la versión estable. Tu rama = borrador seguro donde nada se rompe.
Descripción de qué y por qué, código comentable línea por línea, aprobación antes del merge. Ahí ocurre la revisión real.
Tus suites entran por PR al repo del equipo — y los pipelines de CI corren los tests EN el PR antes de aprobar. Tu trabajo se vuelve gate de calidad.
El flujo branch→PR→review→merge es EL flujo de la industria (GitHub Flow). Para QA doble relevancia: (1) entregan suites por PR, (2) sus tests CORREN en los PRs de otros como gate — su trabajo decide si el código de los devs entra. Convención de nombres de rama: test/*, feat/*, fix/* — el repo profesional la usa.
Segundo simulador: el flujo completo rama → add → commit → push → gh pr create. Es el ensayo general de la misión boss. La lista de objetivos guía el orden; "help" lista comandos válidos. Al completar: la URL del PR simulado aparece — exactamente lo que verán en la realidad.
1. Repo en GitHub conectado (slide 13)
2. Crea una rama para una mejora pequeña (un test nuevo, un script, el POM de otra página):
3. Haz el cambio → add → commit → push:
Tras el push, GitHub imprime una URL "Create a pull request" en la propia terminal — ábrela. O en la web del repo: botón "Compare & pull request".
Hoy: revísalo tú (mira el diff con ojos de reviewer — ¿entenderías este cambio sin contexto?) y dale merge. En equipo real, un colega aprueba. Si están en pareja: ¡revísense mutuamente! Eso es code review real.
El boss produce un artefacto REAL con URL: su primer PR. Si hay pares, crúzalos para review mutuo — el feedback de un colega en un diff es la experiencia profesional completa. El diff del PR en GitHub además les muestra visualmente qué cambió: la utilidad de git se vuelve tangible.
Cierra el arco de motivación: el flujo no es burocracia para equipos grandes, es disciplina profesional con beneficios inmediatos (CI en PRs llega en regression-testing del repo profesional). "El flujo ES el entrenamiento" — frase de cierre del acto.
| Herramienta | Tu nuevo superpoder |
|---|---|
| ⌨️ Terminal | Navegas y ejecutas sin miedo — pwd, cd, Tab, ↑ |
| 📋 package.json | Lees la cédula de cualquier proyecto JS y defines scripts de equipo |
| 📸 Git local | Checkpoints con mensajes dignos — nada se pierde nunca más |
| ☁️ GitHub | Tu código vive en la nube, sobrevive a tu laptop |
| 🔀 Pull Request | Entregas cambios como profesional: propuesta → review → merge |
El repo profesional al que vas usa EXACTAMENTE este flujo (con ramas test/* y prefijos semánticos en commits) — más un detalle: allí bun reemplaza a npm. Mismos conceptos, otro instalador.
Recap-espejo: cada fila es una capacidad que NO tenían al empezar la sesión. El aviso de bun evita el desconcierto en el repo profesional: bun install = npm install, bun run = npm run — conceptos idénticos. Con esto, la única pieza que falta es KATA: el próximo y último deck.
Un commit diario en tu proyecto esta semana — el músculo se hace con repetición. Y termina misiones pendientes.
Tienes TODO: código, clases, Playwright pro, fixtures, git. El próximo deck cruza el puente final al framework profesional.
Penúltima sesión de la serie. Logro: dejaron de ser "personas que escriben tests" y son "profesionales que entregan código" — terminal, scripts, checkpoints, PR con URL real. La tarea del commit diario instala el hábito. Anuncia KATA Bridge como graduación: ya no aprenderán piezas nuevas, sino el mapa de cómo el repo profesional las ensambla.