Testes unitários

Orientação para testes unitários no ecossistema atomus-core (frontend) e Prod-API (backend .NET).

Objetivo

Validar unidades isoladas (funções, serviços de domínio, hooks, utilitários) com execução rápida e determinística, sem rede nem base de dados real salvo quando se usa fakes ou containers de teste explícitos.

Frontend (atomus-core)

• Stack sugerida: Vitest + Testing Library para componentes e hooks que dependem do DOM.
• Onde colocar testes: junto do código (*.test.ts / *.test.tsx) ou pasta __tests__ na mesma feature, conforme convenção que o projeto adotar.
• Âmbito típico: funções em src/lib, resolvers Zod, formatações, hooks com API mockada (MSW ou vi.mock do fetch/cliente).
• Evitar: testes frágeis que acoplam a markup interno de bibliotecas de UI; preferir roles e texto acessível.

Backend (Prod-API)

• Stack: xUnit (ou NUnit), já alinhado ao projeto de testes existente em Prod-API/Tests/.
• Âmbito típico: regras de domínio, value objects, validações que não exijam EF; serviços de aplicação com repositórios mockados ou in-memory.
• Camadas: reforçar que testes de domínio não referenciam EF nem ASP.NET; testes de API podem usar WebApplicationFactory quando fizer sentido (mais próximo de integração).

Comandos (a definir no repositório)

Quando os scripts forem adicionados ao package.json e à solução .NET, documente aqui os comandos oficiais, por exemplo:

• Frontend: npm run test / npm run test -- --watch
• Backend: dotnet test na pasta da solução ou do projeto de testes

Critérios de qualidade

• Um comportamento por teste; nomes que descrevem cenário e resultado esperado.
• Dados de arranjo mínimos; evitar suites que dependem da ordem de execução.
• Falhas devem apontar claramente a regra violada.

---

Atualize esta página quando os runners e scripts estiverem fixados no CI.