FaundrDocumentaçãoAbrir o painelPainel

O painel do projeto

Testes

Testes são pedaços de código que usam o app sozinhos e conferem se o resultado está certo. Com eles, uma mudança do agente que quebra algo antigo aparece na hora, e não semanas depois, quando um cliente reclama.

O Faundr mostra quais testes o projeto tem, se passam, quais estão pulados ou instáveis, quanto do código eles cobrem e, se você quiser ir além, se eles realmente pegam defeitos.

Em que linguagens

O Faundr usa os executores de teste que o projeto já tem, sem instalar nada:

LinguagemExecutores
JavaScript e TypeScriptVitest, Jest, Playwright (testes no navegador), o executor do próprio Node (node --test) e Karma (Angular)
Pythonpytest
Flutter e Dartflutter test e dart test
PHPPHPUnit e Pest
Gogo test
Java e KotlinMaven e Gradle
C#dotnet test
Rustcargo test
C e C++CTest e make test

Para rodar só um deles: !faundr tests-run --runner <nome> (vitest, jest, playwright, node, pytest, flutter, dart, phpunit, pest, go, maven, gradle, dotnet, cargo, ctest, make ou karma). A tabela completa está em Linguagens suportadas.

Os testes nunca rodam sozinhos

No início de cada sessão, o Faundr só faz o inventário: quais executores o projeto usa, quantos arquivos e testes existem e o resultado que já estiver no disco. Ele não roda nada. Os testes rodam quando você ou o agente pedem:

!faundr tests-run

Opções úteis:

  • --changed: só o que mudou desde o último commit;
  • --coverage: mede também a cobertura (veja abaixo);
  • --files <arquivos>: só alguns arquivos.
Banco de produção: se os testes parecem usar o banco de verdade, o Faundr não os roda até você confirmar. O caminho seguro é um arquivo .env.test apontando para um banco de teste.
O Faundr nunca instala nada sozinho. Se faltar uma ferramenta (o executor, a medição de cobertura, o Stryker), ele mostra o comando para você aprovar.

Projeto sem testes

Se o projeto ainda não tem testes, a Visão geral explica o que são e traz o pedido para o agente criar os primeiros: /faundr:tests. O agente:

  1. pergunta o que não pode quebrar (o pagamento? o cadastro?);
  2. liga cada funcionalidade aos testes que a protegem;
  3. escreve os testes que faltam, um de cada vez, testando como quem usa o app, com o resultado esperado escrito à mão e os casos de erro, de vazio e de limite;
  4. vê cada teste novo falhar uma vez antes de confiar nele (um teste que nunca falha pode não estar testando nada).

Abas

Visão geral

  • O card de estado: "N testes falhando" ou "Todos os testes passaram", quantos arquivos e testes existem, os contadores (Passaram, Falhando, Instáveis, Pulados) e a última rodada de cada executor, com data e commit.
  • Funcionalidades e testes: uma linha por funcionalidade, com a etiqueta Protegida, Em parte ou Sem testes. As marcadas como "não pode quebrar" sem testes ficam em destaque.
  • Os grupos Falhando, Instáveis (passam e falham sem o código mudar), Testes que precisam de atenção (problemas de testes encontrados pela Qualidade) e Mais lentos.

Testes

Todos os testes, com os filtros Falhando, Instáveis, Pulados e Todos. Cada linha mostra as últimas 10 rodadas em quadradinhos: branco passou, contorno claro falhou, apagado foi pulado.

O detalhe mostra o que deu errado (a mensagem da falha) e o botão Consertar com a IA (/faundr:tests-fix). O agente explica a falha em português, descobre se o erro está no código ou no teste e conserta a causa. Ele nunca apaga, pula ou afrouxa um teste só para passar. Se não der para saber qual comportamento é o certo, ele pergunta a você.

O que mudou

A pergunta que importa a cada sessão: o que o agente mudou tem teste? Mostra a porcentagem das linhas novas ou mudadas que têm teste e compara com o resto do projeto. A meta é simples: não piorar.

Abaixo, os arquivos da sessão com mais linhas sem teste primeiro, e os arquivos que perderam cobertura sem ninguém mexer neles, o que costuma indicar um teste apagado ou quebrado.

Cobertura

Quanto do projeto tem teste: a porcentagem total e a lista de arquivos, os com mais linhas sem teste primeiro. O detalhe de um arquivo mostra as linhas sem teste e o pedido para o agente escrever os testes.

Cobertura diz que uma linha rodou durante os testes, não que o teste conferiu o resultado dela. Por isso existe a aba Mutação.

A cobertura é medida com !faundr tests-run --coverage. Cada linguagem usa a ferramenta de medição dela, que precisa estar no projeto: @vitest/coverage-v8 no Vitest, pytest-cov no pytest, Xdebug ou PCOV no PHP, coverlet.collector no .NET, cargo-llvm-cov no Rust, gcovr no C/C++ e o plugin JaCoCo no Gradle. Jest, node --test, Flutter, Go e Maven medem sem nada a mais.

Mutação

O teste de mutação responde se os testes pegam defeitos de verdade. O Faundr estraga o código de propósito, um pouco de cada vez (troca um > por >=, apaga uma linha), só nos trechos que a sessão mudou, e vê se algum teste percebe. Cada estrago que passa despercebido vira um T-n, descrito em linguagem simples, como "ninguém testou a compra de exatamente R$ 100".

  • O card mostra "Os testes pegaram N de M defeitos plantados", a nota geral e a nota onde existe teste.
  • O detalhe de um T-n mostra o código, o estrago e o botão Escrever o teste com a IA (/faundr:tests T-n).
  • Ignorar aceita três motivos: o estrago é equivalente (não muda o que o app faz, então nenhum teste consegue pegar), alarme falso ou deixar para depois.

O teste de mutação é opcional e só roda quando pedido: !faundr tests-mutation. Ele precisa do Stryker no projeto e dos testes passando, e tem tempo limitado (5 minutos por padrão). Funciona com testes de JavaScript e TypeScript (Vitest, Jest, node --test).

Achados de outras skills

Se você já usa uma skill de testes que não é do Faundr (de cobertura, TDD, avaliação de testes…), dá para conectá-la ao painel com /faundr:skills. Toda vez que ela roda, no fim da resposta o agente registra o que ela achou:

  • cada falta de teste vira um T-n na aba Mutação, com a etiqueta via /nome, e conta no Lançamento e no Impacto como os outros;
  • quando ela roda de novo e o problema sumiu, ele fecha sozinho;
  • cada skill só fecha os próprios achados, e só nos arquivos que olhou.

Veja como conectar em Workflows.

Erros e testes

Um teste que falha numa rodada do agente também aparece em Erros. Quando o teste volta a passar, o erro fecha sozinho.

Comandos

Testes são pedaços de código que usam o app sozinhos e conferem se o resultado está certo. O Faundr mostra quais testes o projeto tem, se passam, quais estão pulados ou instáveis e os mais lentos. Ele lê Vitest, Jest, Playwright (navegador) e o executor do próprio Node (node --test). Use estes comandos no seu agente de IA, na pasta ligada ao projeto.

No início de cada sessão o Faundr só faz o inventário (quais executores, quantos arquivos e testes, o resultado que já estiver no disco), sem rodar nada. Os testes só rodam quando você ou a IA pedirem. Se os testes parecerem usar o banco de dados de verdade, o Faundr não roda sem a sua confirmação.

  • /faundr:tests [funcionalidade ou arquivo]

    A IA pergunta o que não pode quebrar, liga cada funcionalidade aos testes que a protegem (aparece em Visão geral) e escreve os testes que faltam pelo guia do Faundr: testa como quem usa o app, com o resultado esperado escrito à mão, os casos de erro, vazio e limite, e vê cada teste falhar uma vez antes de confiar nele. Nunca instala nada sem o seu OK.

  • /faundr:tests-fix [teste ou arquivo | --all]

    Conserta um teste falhando ou instável: explica em português o que deu errado, descobre se o erro está no código ou no teste e conserta a causa. Nunca apaga, pula ou afrouxa o teste só para passar; se não der para saber qual comportamento é o certo, pergunta a você. Com --all, conserta todos sem parar e deixa as perguntas para o fim.

    ex.: /faundr:tests-fix src/carrinho.test.ts

  • !faundr tests-run [--changed] [--coverage] [--files <arquivos>] [--runner vitest|jest|playwright|node]

    Roda os testes agora e manda o resultado para cá: quantos passaram, quais falharam e por quê. Com --changed, só o que mudou desde o último commit. Com --coverage, mede também a cobertura: quanto do projeto e do que a sessão mudou tem teste (meta: não piorar) e quais arquivos perderam cobertura sem ninguém mexer. No Vitest, a cobertura precisa do @vitest/coverage-v8 no projeto; o Faundr não instala sozinho. Um teste que passou fecha o erro dele na seção Erros.

  • !faundr tests-mutation [--files <arquivo>] [--budget <minutos>]

    Teste de mutação (opcional): estraga o código de propósito, só nos arquivos que a sessão mexeu, e mostra cada estrago que nenhum teste percebeu (ex.: "ninguém testou a compra de exatamente R$ 100"). Roda só quando pedido, com tempo limitado (5 min por padrão) e com os testes passando. Precisa do Stryker no projeto; o Faundr mostra o comando e não instala sozinho.

    ex.: !faundr tests-mutation --files src/carrinho.ts

  • !faundr tests-ignore T-<n> --reason equivalente|falso-alarme|depois

    Tira um defeito da lista com motivo. "equivalente": o estrago não muda o que o app faz, então nenhum teste consegue pegar.

    ex.: !faundr tests-ignore T-3 --reason equivalente --note "os dois jeitos dão o mesmo resultado"

  • !faundr tests-scan

    Refaz o inventário sem rodar nada: quais executores o projeto usa, quantos arquivos e testes existem e se algum teste parece usar o banco de produção.

  • !faundr tests-show

    Mostra no terminal as últimas rodadas e os testes que estão falhando ou instáveis.

  • !faundr tests-map "<funcionalidade>" [--tests "a.test.ts"] [--critical]

    Liga uma funcionalidade aos testes que a protegem. --critical marca como "não pode quebrar".

    ex.: !faundr tests-map "Pagamento" --tests "carrinho.test.ts" --critical

  • /faundr:browse <endereço> <objetivo>

    Testa um fluxo do app no navegador em segundos (login, cadastro, navegação depois de um deploy), sem prints e sem gastar tokens do agente a cada clique.

    ex.: /faundr:browse localhost:3000 fazer cadastro com um e-mail novo