Tu suite vive solo en tu laptop — para el equipo, no existe.
En esta sesión: terminal con soltura, Git sin miedo y tu primer Pull Request.
Sesión 3 de la serie. El gap silencioso: saben escribir tests pero no compartirlos como profesionales. En esta sesión hay 2 terminales SIMULADAS dentro del deck (practican git sin riesgo) + misiones reales sobre su propia carpeta de práctica, mi-dev-craft, que crean en la misión D1. Prerrequisitos: Coding Base y Coding Classes vistos, Node.js LTS y VS Code instalados (el kit que cierra Coding Base; si falta, nodejs.org y code.visualstudio.com) y una cuenta de GitHub. No depende de ningún deck posterior. 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 proyecto, publicado con PR
En esta sesión 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-dev-craft | 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. Crea tu carpeta de práctica (TypeScript, el resto por defecto):
4. Entra con cd + Tab hasta mi-dev-craft
5. Remata con:
Falta Node.js, el kit que cierra Coding Base: instala la versión LTS desde nodejs.org y reabre la terminal (la vieja no conoce programas nuevos).
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.
mi-dev-craft, lanzado 100% desde la terminal, sin tocar el Finder/Explorador.Misión corta (10-15 min: el instalador de Playwright baja los navegadores) 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-dev-craft",
"scripts": {
"test": "playwright test",
"test:ui": "playwright test --ui"
},
"devDependencies": {
"@playwright/test": "^1.x"
}
}
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 en esta sesión.
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 «GitHub: tu historia, en la nube»)
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".
En este ejercicio: 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 cierran la base de herramientas; el siguiente deck del catálogo es Playwright Pro, y KATA llega después, con Dojo Lab I de por medio.
Un commit diario en tu proyecto esta semana — el músculo se hace con repetición. Y termina misiones pendientes.
Ya tienes código, clases, terminal y git. El próximo deck convierte tus scripts sueltos en una suite profesional: hooks, POM, fixtures y API testing.
Tercera 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 Playwright Pro como siguiente paso: ahí aplican lo aprendido para ordenar su suite. KATA Bridge llega más adelante, cuando ya no aprendan piezas nuevas sino el mapa de cómo el repo profesional las ensambla.