Plugin: Tests automáticos — un comando que escribe tus tests bien

mkdir -p ~/.claude/commands

---
description: Genera tests completos (happy path + edge cases) para la función o archivo apuntado.
argument-hint: <archivo:función o solo archivo>
---

# Generar tests

Objetivo: escribir tests completos para `$ARGUMENTS`.

## Protocolo (no te saltees pasos)

### 1. Detectar el framework

Leé `package.json` y `vitest.config.*` / `jest.config.*` / `playwright.config.*` para detectar:
- Test runner: Vitest, Jest, Bun:test, Node:test, Playwright
- Versión del runner
- Setup files (si existen)
- Convenciones de nombres (`.test.ts`, `.spec.ts`, etc.)

Si no podés detectar, **preguntá** antes de seguir.

### 2. Leer la función objetivo

Leé el archivo completo. No solo la función — también imports y types relevantes.

Si `$ARGUMENTS` apunta a un archivo sin función específica, listame las funciones públicas y preguntame cuáles testear.

### 3. Enumerar edge cases ANTES de escribir

En un solo mensaje al usuario, listá:
- **Happy path**: 1-2 casos
- **Inputs límite**: vacíos, null, undefined, 0, números negativos, strings muy largos
- **Errores esperados**: qué excepciones lanza y cuándo
- **Side effects**: ¿modifica algo? ¿llama a otra cosa? ¿qué hay que mockear?
- **Casos asíncronos**: race conditions, timeouts, cancellations

Esperá confirmación o ajustes del usuario antes de escribir código.

### 4. Escribir los tests

Reglas:
- Un `describe` por función bajo test
- Un `it` por caso enumerado en el paso 3
- Nombres descriptivos: "devuelve null si el input está vacío", NO "test 1"
- Solo mockeás lo que es necesario. No mockees librerías estándar (fs, path) salvo que sea inevitable.
- Si el código depende de tiempo (Date.now, setTimeout), usá `vi.useFakeTimers()` o equivalente
- Imports relativos correctos al archivo de test
- Tests aislados: cada `it` debe poder correr solo

### 5. Verificar

Después de escribir:
- Corré los tests con el comando del proyecto (`npm test`, `pnpm test`, etc.)
- Si algún test falla porque está mal el test (no la función), corregilo
- Si falla porque hay un bug real en la función, reportalo al usuario — NO toques el código de la función para que pase

> /tests src/lib/format-currency.ts

> /tests src/lib/auth.ts:validateToken

Voy a testear `validateToken(token, options)`. Casos identificados:

Happy path:
- Token válido + options vacíos → devuelve { valid: true, payload }

Inputs límite:
- token = "" → debería tirar TokenError
- token = null → debería tirar TokenError
- token con formato JWT pero firma inválida → { valid: false }

Side effects:
- Llama a `verifyJWT` (necesito mock)
- No tiene otros side effects observables

Asíncrono:
- La función es async, hay que await

¿Algún caso que quieras agregar o sacar?

---
description: Tests rápidos, solo happy path (3 casos máx)
argument-hint: <archivo:función>
---

Escribí 3 tests para `$ARGUMENTS`, solo happy path. No enumeres edge cases. Devolveme el archivo de test listo.

---
description: Genera test e2e con Playwright para el flow descrito
argument-hint: <descripción del flow>
---

Escribí un test e2e de Playwright para: $ARGUMENTS

Protocolo:
1. Leé playwright.config.ts y los tests existentes (si hay) para detectar el patrón del proyecto
2. Identificá qué pages/selectors vas a necesitar
3. Escribí el test usando page object pattern si el proyecto ya lo usa
4. Las assertions deben usar `expect(page.locator(...)).toBeVisible()` style, no `toBe` con `.textContent()`

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "if echo \"$CLAUDE_FILE_PATHS\" | grep -qE '\\.(test|spec)\\.(ts|tsx|js)'; then npm test -- --run \"$CLAUDE_FILE_PATHS\" 2>&1 | tail -20; fi"
          }
        ]
      }
    ]
  }
}