Componentes para escrever, correr e avaliar testes com o Claude Code.
Numa base de código sem testes, cada alteração obriga a verificar à mão aquilo que já funcionava. O problema costuma aparecer quando a equipa cresce ou quando uma correção antiga volta a partir. Os testes automatizados são a rede que apanha essas regressões antes do utilizador, mas escrevê-los é trabalho lento: é preciso perceber o código, inventar casos-limite, preparar dados de teste e manter tudo isso vivo à medida que o projeto muda.
Os componentes desta página passam parte desse trabalho para o Claude Code. Uns leem um ficheiro de origem e devolvem o ficheiro de teste correspondente, com mocks e casos-limite já pensados. Outros analisam a cobertura existente e apontam os ramos que ninguém exercita. Há ainda automações que correm a suite sempre que um ficheiro é editado, e conetores que abrem um browser real para validar percursos completos de utilizador.
Comece pelo problema que tem hoje. Se o projeto já tem testes e quer aumentar a cobertura, um comando de geração e um relatório de cobertura chegam para as primeiras semanas. Se está a arrancar com uma funcionalidade nova, vale mais adotar o ciclo teste primeiro. Se o que falha são fluxos de interface, salte para o grupo de ponta a ponta. Instale poucos componentes de cada vez e mantenha só os que realmente usa.
21 componentes escolhidos à mão, de 4 ângulos diferentes.
O caso mais comum: há código em produção e pouca ou nenhuma cobertura. Estes componentes leem o que existe e produzem testes unitários e de integração alinhados com as convenções do projeto.
Indique um ficheiro ou o nome de um componente e receba o ficheiro de teste completo, já alinhado com o framework detetado no projeto (Jest, Vitest, Mocha ou Jasmine).
Gerar um ficheiro de teste completo para um ficheiro de origem ou componente especificado. Usar quando o utilizador pedir explicitamente para escrever
Serve quando quer decidir o tipo de teste à partida: aceita unitário, integração, ponta a ponta ou componente como argumento, e trata do mocking e da configuração de cobertura.
Escrever testes unitários e de integração abrangentes com mocking e cobertura adequados
Para quem escreve em Jest e quer convenções estáveis: funções de fábrica para dados falsos, estratégias de mocking e a disciplina de testar comportamento em vez de implementação.
Padrões de teste Jest, factory functions, estratégias de mocking e fluxo de trabalho TDD. Usar ao escrever testes unitários, criar test factories ou s
O equivalente do lado do Python, com pytest, fixtures, parametrização e mocking de dependências externas, incluindo código assíncrono. Escolha-o se a suite vive em pytest.
Implemente estratégias de teste abrangentes com pytest, fixtures, mocking e desenvolvimento guiado por testes. Use ao escrever testes em Python, confi
Indicado quando não existe suite nenhuma e é preciso montar as três camadas de uma vez, incluindo dados de teste, fábricas e a configuração do pipeline de CI.
Criar suítes de testes abrangentes com testes unitários, de integração e e2e. Configura pipelines de CI, estratégias de mocking e dados de teste. Util
Trabalha um nível acima do ficheiro: define a estratégia, distribui o esforço pela pirâmide de testes e fixa limiares de qualidade antes de alguém escrever a primeira asserção.
Especialista em automatização de testes e garantia de qualidade. Utilize PROATIVAMENTE para estratégia de testes, automatização de testes, análise de
Quando a funcionalidade ainda não existe, escrever o teste antes do código muda o desenho do resultado. Estes componentes impõem o ciclo vermelho, verde, refatoração em vez de deixar o modelo saltar diretamente para a implementação.
A referência curta do ciclo, com as três leis do TDD e as regras de cada fase. Útil para manter o assistente dentro da disciplina durante sessões longas.
Princípios do fluxo de trabalho de Desenvolvimento Orientado por Testes. Ciclo RED-GREEN-REFACTOR.
Escreve os testes que falham a partir do contexto de um issue no GitHub, extraindo requisitos, critérios de aceitação e casos-limite antes de existir qualquer implementação.
Guiar o desenvolvimento test-first escrevendo testes que falham que descrevem o comportamento pretendido a partir do contexto do issue do GitHub antes
A fase seguinte: implementa apenas o mínimo para os testes passarem e resiste de forma explícita a alargar o âmbito para além do que o issue pede.
Implementar código mínimo para satisfazer os requisitos do issue do GitHub e fazer passar os testes com falhas sem over-engineering.
Fecha o ciclo com remoção de duplicação, melhorias de desenho e boas práticas de segurança, sempre com a condição de manter todos os testes verdes.
Melhorar a qualidade do código, aplicar melhores práticas de segurança e aprimorar o design, mantendo os testes a verde e a conformidade com o issue d
Testes unitários não apanham um botão que deixou de submeter o formulário. Este grupo cobre percursos reais de utilizador num browser e as diferenças visuais entre versões.
Para quem ainda não decidiu entre Cypress, Playwright, WebDriver ou Puppeteer: analisa o projeto, escolhe o framework e liga a suite ao sistema de CI que já existe.
Configurar uma suite de testes end-to-end abrangente com seleção de framework e integração de CI
Vai mais fundo em Playwright, com Page Object Model, persistência do estado de autenticação, fixtures próprias e paralelização, começando por uma entrevista sobre os fluxos críticos.
Planear e criar suites de testes E2E Playwright abrangentes com Page Object Model, persistência de estado de autenticação, fixtures personalizadas, re
Dá ao Claude Code um browser a sério para navegar, tirar capturas de ecrã e executar JavaScript na página, útil para reproduzir um bug antes de o transformar em teste.
Um servidor Model Context Protocol que fornece capacidades de automação de browser usando o Playwright. Este servidor permite que os LLMs interajam co
Quando a regressão é visual e não funcional: configura comparação de imagens entre browsers, em vários tamanhos de ecrã, ao nível do componente ou da página inteira.
Configurar testes abrangentes de regressão visual com testes cross-browser e responsivos
Ter testes não chega, é preciso saber se valem alguma coisa e garantir que correm. Aqui ficam a análise de cobertura, as técnicas que testam os próprios testes e a rotina de execução.
Separa cobertura de linha, de ramo, de função e de instrução, e mostra onde estão os buracos, em vez de uma percentagem única que esconde o que falta.
Analisar e melhorar a cobertura de testes com relatórios abrangentes e identificação de lacunas
Uma suite grande também pode ser má. Avalia eficácia, manutenibilidade e tempo de execução dos testes existentes e sugere o que cortar ou reescrever.
Analisar a qualidade do conjunto de testes com métricas abrangentes e recomendações de melhoria
Introduz mutações no código para ver se algum teste as apanha, com Stryker, PIT, mutmut ou cargo-mutants. É a forma mais honesta de perceber se a cobertura significa alguma coisa.
Configurar testes de mutação abrangentes com seleção de framework e integração CI
Em vez de exemplos escolhidos à mão, identifica invariantes e gera entradas com fast-check, Hypothesis, QuickCheck ou proptest. Compensa em lógica de domínio cheia de casos-limite.
Implementar testes baseados em propriedades com seleção de framework e identificação de invariantes
Automação PostToolUse que corre os testes relevantes assim que um ficheiro é editado, reconhecendo projetos JavaScript, Python e Ruby sem configuração adicional.
Executa automaticamente testes relevantes após alterações ao código. Deteta ficheiros de teste e executa os comandos de teste adequados com base nas e
Traz scripts próprios para gerar suites, analisar cobertura e montar o esqueleto dos testes de ponta a ponta, orientados a aplicações React, Next.js e Node.js.
Competência abrangente de QA e testes para garantia de qualidade, automatização de testes e estratégias de teste para aplicações ReactJS, NextJS, Node
Cobre o lado manual do QA: planos de teste, casos escritos, suites de regressão e relatórios de bug, com validação de ecrãs contra ficheiros do Figma.
Gere planos de teste abrangentes, casos de teste manuais, suites de testes de regressão e relatórios de bugs para engenheiros de QA. Inclui integração
Cada categoria tem um sítio próprio. Os agentes são ficheiros markdown em .claude/agents/ dentro do projeto, ou em ~/.claude/agents/ se quiser tê-los em todos os projetos. As skills ficam em .claude/skills/<nome>/SKILL.md e são carregadas quando o pedido corresponde à descrição. Os comandos ficam em .claude/commands/<nome>.md e invocam-se com barra, por exemplo /generate-tests src/auth.ts. As automações (hooks) são blocos de configuração no settings.json, com o evento e o comando de shell a executar. Os conetores MCP registam-se na configuração de servidores MCP e arrancam por npx quando a sessão começa. Instale ao nível do projeto sempre que a configuração dependa do framework de testes usado nesse repositório.
Um encadeamento que funciona em código existente: corra primeiro o comando de cobertura para saber que ficheiros estão descobertos, depois gere testes ficheiro a ficheiro pelos módulos mais críticos, e só no fim ligue a automação que corre a suite a cada edição. Assim evita ter uma automação a falhar em todas as gravações enquanto a suite ainda está incompleta. Para os módulos onde um erro custa dinheiro ou dados, acrescente testes de mutação: se as mutações sobreviverem, os testes existem mas não verificam nada. Em funcionalidade nova, o encadeamento é outro: skill de TDD, agente da fase vermelha, agente da fase verde, agente de refatoração.
Testes gerados a partir de código existente descrevem o comportamento atual, incluindo os bugs. Se o objetivo é validar requisitos, alguém tem de rever cada asserção e confirmar que descreve o que deveria acontecer, não o que acontece. A percentagem de cobertura também não é qualidade: dá para chegar a números altos sem uma única asserção útil, e é por isso que a análise de mutação existe. Nos testes de ponta a ponta conte com lentidão e falhas intermitentes, sobretudo em ecrãs com animações ou dados variáveis. E nenhum destes componentes decide o que é crítico no seu produto, essa parte continua a ser sua.
Não, e não é aconselhável. Cada skill e cada agente ocupam contexto e competem entre si quando fazem coisas parecidas. Escolha um componente por necessidade real: um para gerar testes, um para medir cobertura, e acrescente os de ponta a ponta apenas quando tiver fluxos de interface que valha a pena cobrir.
Rever diffs, apanhar bugs antes do merge e reduzir dívida técnica.
Encontrar a causa raiz: stack traces, logs, incidentes e fugas de memória.
Componentes para empacotar, publicar e manter software a correr em produção.
Prompts e recursos curados de fontes internacionais, normalizados e categorizados: mais de 11 mil. Um robô do Doutor AI verifica as fontes todos os dias e traz o que há de novo.
Precisa de uma solução à medida?
Não sabe por onde começar a usar IA no seu negócio? Receba uma avaliação gratuita e um plano à medida - sem compromisso.
O Doutor AI dá-lhe 1859 prompts de IA prontos a copiar, por indústria e em português simples - mais uma biblioteca técnica completa para quem quer ir mais longe.
