Plano: testes unitários para a API

[wilsontayar]

Contexto

A API do Dev Garage hoje não tem nenhuma cobertura de testes — não há framework configurado no package.json. A lógica é simples mas crítica: validação de payloads (lib/http.ts), o store em memória (lib/store.ts) e os route handlers em app/api/**. Esta issue propõe um plano para introduzir testes unitários.

Objetivo

Configurar uma suíte de testes unitários rápida e estabelecer cobertura para a camada de validação, o store e os route handlers da API.

Stack proposta

• Vitest — rápido, ESM-first (o projeto é "type": "module") e integra bem com o setup de TS/Next.
• Resolver o alias @/* no config do Vitest (espelhando o tsconfig.json).
• Adicionar scripts ao package.json: test e test:watch.

Plano de implementação

1. Setup

• Adicionar vitest como devDependency.
• Criar vitest.config.ts com o alias @/ apontando para a raiz e ambiente node.
• Adicionar scripts test / test:watch ao package.json.

2. lib/http.ts — validação (maior prioridade, lógica pura, sem mocks)

• parseCreateProject: nome obrigatório, trim, limite de 80 chars; description opcional (tipo + limite 500); status default idea e rejeição de status inválido; tags (lista de strings, trim, dedupe, corte em 10).
• parseUpdateProject: patch parcial; rejeitar name vazio; validar tipos/limites de cada campo.
• parseCreateTask: title obrigatório, trim, limite 140.
• parseUpdateTask: patch parcial de title/done; erro "Nada para atualizar" quando vazio; done precisa ser booleano.
• Helpers badRequest/notFound retornam status e corpo corretos.

3. lib/store.ts — CRUD em memória

• listProjects retorna summaries com taskCount/doneCount corretos e ordenados por createdAt desc.
• getProject inclui tasks ordenadas; retorna undefined para id inexistente.
• createProject / updateProject (patch parcial) / deleteProject (cascata nas tasks).
• addTask retorna undefined para projeto inexistente; updateTask / deleteTask.
• Resetar o estado entre testes (o store usa um singleton em globalThis.__devGarageDb).

4. Route handlers (app/api/**)

• Testar os handlers exportados (GET/POST/PATCH/DELETE) passando Request e o params (lembrar que params é uma Promise).
• Cobrir caminhos: JSON inválido → 400, validação falha → 400, recurso não encontrado → 404, sucesso → 200/201/204.

Critérios de aceite

• pnpm test roda verde localmente.
• lib/http.ts e lib/store.ts com cobertura alta dos ramos.
• Cada route handler com ao menos um caso de sucesso e um de erro.

Fora de escopo

• Testes E2E / de integração com servidor real.
• Testes de componentes React / UI.