vibe-testing

Testes de navegador Playwright com consciência de código para agentes de codificação de IA, com 14 ferramentas MCP, memória de regressão e relatórios HTML.

GitHub

Documentação

vibe-testing

Testes de navegador com ciência do código para agentes de IA de codificação.

Site do produto · npm · MCP Registry · Smithery · Privacidade · Status de lançamento

Listado em Awesome MCP Servers. O selo de download mostra os downloads acumulados do pacote npm; npx buscas de pacotes contribuem para esse total.

O vibe-testing lê seu código para que os testes usem suas rotas e nomes de campos reais, executa-os em um navegador Playwright real, lembra o que quebrou e informa o que sua última alteração corrigiu ou regrediu. Ele funciona como um servidor MCP que dá ao seu editor (Claude Code, Cursor, Windsurf, VS Code Copilot, Roo Code) 14 ferramentas de teste, ou como uma CLI autônoma.

O repositório também é um Agent Plugin com uma habilidade release-qa. Agentes compatíveis recebem tanto as ferramentas de teste quanto um fluxo de trabalho de QA sênior para cobertura, evidências, verificações de regressão e um veredito claro de lançamento.

cd /path/to/your/project
npx vibe-testing@latest init

Em seguida, abra seu editor e diga:

"Escaneie este código e teste-o contra http://localhost:3000"

O que os testes com ciência do código adicionam

O Playwright MCP dá mãos ao seu agente. O vibe-testing dá a ele um fluxo de trabalho de teste: cenários derivados do código, memória entre execuções e um relatório. Duas coisas que uma ferramenta de navegador sem estado não pode fazer:

1. Execute duas vezes e ele informa o que você quebrou. Cada execução grava .vibe/run-snapshot.json e compara com a execução anterior. Cada varredura grava .vibe/route-manifest.json e compara suas rotas. A segunda execução imprime regressões e correções em vez de uma parede de resultados:

Changes since last run
  Fixed:      /login
  Regression: /checkout
  New:        /admin/users

O mesmo diff chega ao seu editor como snapshot_diff em run_full_test e run_converge, e como route_changes em scan_codebase, para que o agente possa sinalizar "o checkout quebrou após esse commit" sem que ninguém role um relatório. Rotas instáveis, seletores funcionais e tempos limite medidos também são lembrados entre execuções.

2. Zero chamadas de LLM dentro da ferramenta. A verificação de aprovação/reprovação é heurística: mudanças de URL, detecção de toast, erros de API. O modelo do seu editor decide o que testar; o vibe-testing faz a navegação e a verificação. Sem chave de API, sem custo por execução além da assinatura do editor que você já paga.

Como funciona

npx vibe-testing@latest init
        |
Registers 14 MCP tools in your editor
        |
You ask: "Test the checkout flow"
        |
AI calls: scan_codebase -> get_context("checkout") -> login -> explore_page -> execute_scenario -> generate_report
        |
HTML report opens in browser with screenshots of every step

Sem casos de teste para escrever. A IA lê seu código-fonte para entender nomes de campos e rotas reais, abre um navegador, testa tudo e mostra o que está quebrado.

init também:

Detecta quais editores de IA você tem instalados
Registra o vibe-test nas configurações globais do editor (~/.claude/settings.json, ~/.cursor/mcp.json e assim por diante) para que as ferramentas estejam disponíveis em todos os projetos e sessões
Cria configurações MCP no nível do projeto e arquivos de instruções de IA
Detecta automaticamente a URL do seu aplicativo (lê .env, vite.config, padrões do framework)
Cria VIBE.md (edite com suas credenciais de teste) e vibe.config.json
Instala a versão correspondente do Playwright Chromium

Configuração do MCP

Agent Plugin

Instale este repositório como um plugin quando seu agente suportar o padrão Agent Plugins. Ele inclui a habilidade portátil release-qa e inicia o servidor MCP npm publicado sem chave de API.

Cursor: envie ou instale https://github.com/AishwaryShrivastav/vibe-testing como um Agent Plugin.

Claude Code:

claude plugin marketplace add AishwaryShrivastav/vibe-testing
claude plugin install vibe-testing@vibe-testing

Outros agentes compatíveis: carregue a raiz do repositório contendo plugin.json, skills/ e mcp.json.

A configuração direta de MCP e CLI abaixo permanece disponível para editores sem suporte a plugins.

Pacote MCPB

O Claude Desktop e outros hosts MCPB podem instalar um único pacote local. Compile e valide-o a partir deste repositório:

npm ci
npm run build:mcpb

O artefato é gravado em artifacts/vibe-testing-<version>.mcpb. Consulte o guia de distribuição MCPB para o conteúdo do pacote, etapas de validação, transferência para o Smithery e o pré-requisito único do Playwright Chromium.

Opção 1: automática (recomendada)

npx vibe-testing@latest init

Detecta e configura todos os editores instalados. Pronto.

Opção 2: manual por editor

Claude Code

Adicione a ~/.claude/settings.json (global, funciona em todos os projetos):

{
  "mcpServers": {
    "vibe-test": {
      "command": "npx",
      "args": ["-y", "vibe-testing@latest", "--mcp"]
    }
  }
}

Ou adicione a .mcp.json na raiz do seu projeto (somente no nível do projeto):

{
  "mcpServers": {
    "vibe-test": {
      "command": "npx",
      "args": ["-y", "vibe-testing@latest", "--mcp"]
    }
  }
}

Cursor

Adicione a ~/.cursor/mcp.json (global) ou .cursor/mcp.json (projeto):

{
  "mcpServers": {
    "vibe-test": {
      "command": "npx",
      "args": ["-y", "vibe-testing@latest", "--mcp"]
    }
  }
}

Windsurf

Adicione a ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "vibe-test": {
      "command": "npx",
      "args": ["-y", "vibe-testing@latest", "--mcp"]
    }
  }
}

VS Code (GitHub Copilot)

Adicione a .vscode/mcp.json no seu projeto:

{
  "servers": {
    "vibe-test": {
      "command": "npx",
      "args": ["-y", "vibe-testing@latest", "--mcp"]
    }
  }
}

Roo Code / Cline

Adicione a .roo/mcp.json:

{
  "mcpServers": {
    "vibe-test": {
      "command": "npx",
      "args": ["-y", "vibe-testing@latest", "--mcp"]
    }
  }
}

A partir de build local (desenvolvimento)

{
  "mcpServers": {
    "vibe-test": {
      "command": "node",
      "args": ["/path/to/vibe-testing/dist/mcp-server.js"]
    }
  }
}

Referência das ferramentas MCP

14 ferramentas disponíveis para seu editor de IA após a configuração:

Ferramenta	Quando chamar	Retorna
`configure`	Comece aqui em um novo projeto. Detecta framework, servidor e autenticação	Resultado de configuração estruturado e arquivos de projeto idempotentes
`scan_codebase`	Sempre primeiro. Lê o código-fonte, encontra rotas/formulários/testes/lacunas	Rotas, formulários, mapa de cobertura, cenários gerados, `route_changes` desde a última varredura
`get_context`	Antes de escrever etapas de teste. Retorna arquivos de origem para um recurso	Código-fonte real com nomes de campos e seletores reais
`login`	Quando o aplicativo exige autenticação	Captura de tela pós-login, estado do token, chamadas de API observadas
`scan_page_elements`	Para ver todos os elementos interativos em uma página	Lista de elementos com seletores mais captura de tela da página
`explore_page`	Teste amplo de "tudo funciona?"	Resultados de interação, chamadas de API, erros, captura de tela
`execute_scenario`	Executar etapas de teste específicas	Logs passo a passo mais capturas de tela
`get_coverage`	Ver mapa de cobertura e rotas não testadas	Entradas de cobertura, lacunas, cenários disponíveis
`suggest_tests`	Encontrar lacunas de cobertura após exploração	Cenários priorizados e prontos para execução com etapas
`take_screenshot`	Verificação visual rápida	Captura de tela de qualquer URL
`generate_report`	Criar relatório HTML (abre automaticamente)	Caminho do relatório mais resumo
`run_full_test`	Execução única: varredura, execução, exploração, relatório	Resultados completos mais `snapshot_diff` vs última execução
`run_converge`	Teste iterativo até atingir limites	Resumo de todas as rodadas mais `snapshot_diff` vs última execução
`cleanup`	Fechar navegadores, liberar recursos	-

Entradas das ferramentas

scan_codebase

{
  "codebase_path": "/path/to/project",
  "url": "http://localhost:3000",
  "mode": "deep"
}

get_context

{ "feature": "login" }
{ "feature": "/checkout" }
{ "feature": "user profile form" }

login

{
  "email": "test@example.com",
  "password": "TestPass123!",
  "login_url": "/login"
}

scan_page_elements / explore_page

{
  "route": "/dashboard",
  "authenticated": true
}

execute_scenario

{
  "scenario": {
    "id": "create-item",
    "name": "Create a new item",
    "route": "/items",
    "steps": [
      { "action": "navigate", "url": "/items", "description": "Open items page" },
      { "action": "click", "selector": "text=Add Item", "description": "Open create form" },
      { "action": "fill", "selector": "[name='title']", "value": "Test Item", "description": "Fill title" },
      { "action": "fill", "selector": "[name='description']", "value": "Test description", "description": "Fill description" },
      { "action": "click", "selector": "button[type='submit']", "description": "Submit form" }
    ],
    "expected_outcome": "New item appears in the list",
    "requires_auth": true
  }
}

Ações de etapa: navigate, fill, click, select, wait, assert, upload

A CLI e o MCP usam o mesmo executor de cenários. Uma etapa assert avalia cada condição fornecida:

selector: o alvo deve estar visível. CSS, text=, label= e placeholder= são suportados; os localizadores nomeados correspondem exatamente.
value: o texto visível deve conter esta string, no elemento selecionado ou no corpo da página quando nenhum seletor for fornecido.
url: a URL atual deve corresponder exatamente a esta URL absoluta ou caminho resolvido contra a URL base configurada, incluindo query e fragmento.

Por exemplo:

{ "action": "assert", "selector": "#confirmation", "value": "Saved", "url": "/settings", "timeout": 5000, "description": "Check saved settings" }

Essas verificações aguardam até o tempo limite da etapa (padrão 15000 ms por verificação). Uma asserção com falha interrompe o cenário, registra uma etapa com falha e o motivo, e retorna status: "fail"; o MCP também define isError: true. Condições explícitas são usadas como o veredito após as verificações existentes de autenticação e API de formulário. O texto em prosa description e expected_outcome não são asserções executáveis. Sem selector, value ou url, assert apenas verifica a saúde da página: pelo menos 10 caracteres de texto visível no corpo e nenhum indicador de erro visível não vazio. Essa verificação de compatibilidade não prova um resultado de negócio descrito.

upload requer um selector de entrada de arquivo e um caminho de arquivo não vazio em value. Caminhos relativos são resolvidos em relação à raiz do código. Entradas de arquivo ocultas são suportadas. Um arquivo ausente, diretório, alvo ausente ou alvo que não é uma entrada de arquivo retorna status: "error". A ação seleciona um arquivo usando Playwright; adicione uma asserção da UI resultante para verificar o processamento no lado do aplicativo. Ela não automatiza diálogos nativos de seleção de arquivo.

Os cenários devem conter pelo menos uma etapa. Ações desconhecidas são erros.

take_screenshot

{ "url": "/settings", "authenticated": true, "full_page": false }

run_full_test

{ "url": "http://localhost:3000", "codebase_path": "/path/to/project", "mode": "deep" }

run_converge

{
  "url": "http://localhost:3000",
  "max_followup_rounds": 4,
  "target_pass_rate": 0.92,
  "max_high_severity_gaps": 2
}

Fluxo de trabalho recomendado

Sessão de teste completa

Diga ao seu editor de IA:

Scan this codebase and test it against http://localhost:3000.
Log in with test@example.com / pass123. Explore the dashboard and
settings pages, run the suggested tests, and generate a report.

A IA irá:

scan_codebase, para entender rotas, formulários, testes existentes
get_context("login"), para ler o código-fonte real do formulário de login
login, para autenticar em um navegador real
explore_page("/dashboard"), clicando em tudo e observando o que quebra
explore_page("/settings"), o mesmo
suggest_tests, para encontrar lacunas de cobertura
execute_scenario x N, executando fluxos de teste direcionados
generate_report, o relatório HTML abre automaticamente
cleanup, fechando navegadores

Testar um recurso específico

Test the checkout flow using vibe-test. Get context for checkout,
then run the full purchase flow with card number 4242424242424242.

A IA irá:

scan_codebase (se ainda não feito)
get_context("checkout"), lendo CheckoutForm.tsx, api/orders/route.ts e assim por diante
login
execute_scenario, preenchendo os campos reais do formulário a partir do código-fonte
generate_report

Verificar uma correção de bug

I fixed the login redirect bug. Use vibe-test to confirm it's working.

A IA irá:

login, testando o fluxo de login
take_screenshot, confirmação visual do estado pós-login
Relatar o que vê

Encontrar o que está quebrado

Explore every page and tell me what's broken.

A IA executará explore_page em cada rota, coletando erros de API, elementos quebrados e interações com falha, depois suggest_tests com os itens quebrados marcados como alta prioridade.

Comando init

npx vibe-testing@latest init [options]

O que ele cria:

Arquivo	Onde	Propósito
`.mcp.json`	Raiz do projeto	Configuração MCP do Claude Code (nível do projeto)
`~/.claude/settings.json`	Global	Configuração MCP do Claude Code (todos os projetos)
`.cursor/mcp.json`	Raiz do projeto	Configuração MCP do Cursor
`~/.cursor/mcp.json`	Global	Configuração MCP do Cursor (todos os projetos)
`.cursor/rules/vibe-test.mdc`	Projeto	Regras do Cursor, `alwaysApply: true`
`.windsurfrules`	Projeto	Instruções do Windsurf
`~/.codeium/windsurf/mcp_config.json`	Global	Configuração MCP do Windsurf (todos os projetos)
`.vscode/mcp.json`	Projeto	Configuração MCP do VS Code Copilot
`.github/copilot-instructions.md`	Projeto	Instruções do GitHub Copilot
`.roo/mcp.json`	Projeto	Configuração MCP do Roo Code
`CLAUDE.md`	Projeto	Instruções de sessão do Claude Code
`AGENTS.md`	Projeto	Instruções universais de agente (Codex, Devin, Zed)
`VIBE.md`	Projeto	Orientação de teste, edite com suas credenciais
`vibe.config.json`	Projeto	Configuração, URL detectada automaticamente do seu projeto

Opções:

npx vibe-testing@latest init                     # auto-detect editors, register globally + project
npx vibe-testing@latest init --no-global         # project-level only, skip global registration
npx vibe-testing@latest init --skip-browser-install
npx vibe-testing@latest init --editor cursor     # only configure Cursor
npx vibe-testing@latest init --editor claude-code windsurf

Após o init, edite VIBE.md com sua URL de login e credenciais de teste.

Comandos da CLI

# Set up in current project
npx vibe-testing@latest init

# Install or repair the matching browser build
npx vibe-testing@latest install-browser

# Run tests against a URL
npx vibe-testing@latest run http://localhost:3000
npx vibe-testing@latest run https://staging.myapp.com --mode deep
npx vibe-testing@latest run http://localhost:3000 --codebase /path/to/project --scope /login /dashboard

# Iterative testing until coverage thresholds
npx vibe-testing@latest converge http://localhost:3000
npx vibe-testing@latest converge http://localhost:3000 --max-rounds 6 --target-pass-rate 0.95

# Open last report in browser
npx vibe-testing@latest report

# Reset memory and screenshots for a clean run
npx vibe-testing@latest reset

Opções de `run`

Opção	Padrão	Descrição
`--mode fast\|deep`	`deep`	`fast`: varredura rápida. `deep`: extração completa de recursos mais exploração
`--no-headed`	-	Executar o navegador em modo headless (padrão: visível)
`--codebase <path>`	cwd	Caminho para a raiz do projeto
`--scope <routes...>`	all	Testar apenas rotas específicas
`-c <path>`	`vibe.config.json`	Caminho do arquivo de configuração

run e converge falham com código de saída diferente de zero quando nenhum cenário é descoberto ou um lote de execução está vazio. MCP run_full_test e run_converge retornam isError: true para esses casos. Execuções vazias não gravam um snapshot de execução bem-sucedido nem substituem o relatório anterior.

Opções de `converge`

Opção	Padrão	Descrição
`--max-rounds <n>`	`4`	Máximo de rodadas de acompanhamento após a linha de base
`--target-pass-rate <r>`	`0.92`	Parar quando a taxa de aprovação atingir este valor (0-1)
`--max-gaps <n>`	`2`	Parar quando as lacunas críticas e importantes caírem para este valor

VIBE.md, orientação do projeto

Crie VIBE.md na raiz do seu projeto. O vibe-testing o lê automaticamente em toda execução.

## Login URL
/login

## Test Credentials
- Email: test@example.com
- Password: TestPass123!

## Never Automate
- delete account
- cancel subscription
- [data-testid="danger-zone"]
- .billing-section

## Known Flaky
- /notifications (WebSocket dependent, skip or expect retry)
- /live-feed

## Notes
- Admin panel at /admin, use admin@example.com / adminpass
- Dashboard data loads async, wait for [data-loaded="true"]
- Profile page: click "Edit Profile" before form fields appear

Consulte VIBE.example.md para o modelo completo.

Configuração

vibe.config.json

Criado automaticamente por init com URL auto-detectada. Edite conforme necessário:

{
  "url": "http://localhost:3000",
  "mode": "deep",
  "auth": {
    "strategy": "credentials",
    "login_url": "/login",
    "credentials": {
      "email": "test@example.com",
      "password": "TestPass123!"
    }
  },
  "never_interact": [
    "delete account",
    "cancel subscription",
    "[data-testid='danger-zone']"
  ],
  "scope": {
    "include": ["/**"],
    "exclude": ["/admin/**", "/api/**"],
    "max_routes": 30,
    "seed_routes": ["/live/dev-mode-a-now"]
  },
  "browser": {
    "headed": true,
    "slowMo": 40,
    "timeout": 30000
  }
}

Chave	Descrição
`url`	URL do aplicativo, localhost ou staging. Auto-detectada por `init`.
`mode`	`fast` (varredura heurística) ou `deep` (extração completa mais exploração)
`auth.strategy`	`credentials` (login por formulário), `basic` (HTTP Basic Auth) ou `skip`
`auth.login_url`	Rota de login explícita para caminhos não padronizados que a correspondência de palavras-chave não detectaria
`auth.credentials`	Credenciais de login, usadas para login e para cenários gerados, persistidas entre execuções
`never_interact`	Padrões de texto ou seletores CSS para ignorar durante a exploração
`scope.include`	Padrões de rota a incluir; o padrão `/*` inclui `/` e todas as rotas aninhadas. `` permanece dentro de um segmento; um `/**` final inclui a raiz da subárvore e seus descendentes. Outros caracteres são literais.
`scope.exclude`	Padrões de rota a excluir dos testes
`scope.max_routes`	Limite de quantas rotas são testadas por execução
`scope.seed_routes`	URLs concretas para rotas de segmento dinâmico que o parser não consegue enumerar (ex.: `/live/[slug]` torna-se `/live/dev-mode-a-now`). Cada rota semeada herda `requires_auth` e o arquivo de origem do seu pai dinâmico.
`browser.headed`	`true` = navegador visível. Padrão da CLI `true`, padrão do servidor MCP `false` (headless) para que sessões do editor não sejam interrompidas por janelas pop-up.
`browser.slowMo`	Milissegundos entre ações (útil para depuração)
`routes`	`auto` (padrão) descobre rotas a partir do código. `config` usa apenas rotas listadas explicitamente na configuração.

Frameworks suportados

Framework	Rotas	Endpoints de API	Formulários
Next.js App Router	sim	sim	sim
Next.js Pages Router	sim	sim	sim
Next.js (variante src/)	sim	sim	sim
React SPA (react-router)	sim	-	sim
Vue + Vite (vue-router)	sim	-	sim
Nuxt	sim	sim	sim
SvelteKit	sim	sim	sim
Express / Fastify	-	sim	sim
Monorepos (Turborepo, pnpm, Lerna)	sim	sim	sim

Arquivos de teste existentes também são lidos para construir um mapa de cobertura: suítes Jest, Vitest, Playwright e Cypress são todas analisadas.

Memória e detecção de regressões

O vibe-testing aprende entre execuções e armazena estado em .vibe/:

Seletores funcionais: lembra [name='email'] funcionou em /login, usa na próxima execução
Tempos de rota: ajusta timeouts com base nos tempos de carregamento medidos
Credenciais de autenticação: salvas após o primeiro login, reutilizadas automaticamente
Rotas instáveis: rastreia rotas com alta taxa de falha, marca-as para nova tentativa
Rotas ignoradas: rotas que falham consistentemente (precisam de parâmetros de URL) são ignoradas automaticamente
Manifesto de rotas (.vibe/route-manifest.json): cada varredura faz diff com a anterior; rotas novas e removidas aparecem como route_changes nos resultados de scan_codebase para que a IA possa cobri-las imediatamente
Snapshot de execução (.vibe/run-snapshot.json): cada execução captura aprovação/reprovação por rota e faz diff com a execução anterior; snapshot_diff sinaliza newly_passing (correções), newly_failing (regressões), still_failing, além de rotas adicionadas e removidas

{
  "snapshot_diff": {
    "newly_passing": ["/login"],
    "newly_failing": ["/checkout"],
    "still_failing": [],
    "new_routes": ["/admin/users"],
    "removed_routes": []
  }
}

run_converge retorna o mesmo formato, para que execuções iterativas no seu editor destaquem o que você acabou de quebrar.

Redefina com npx vibe-testing@latest reset para começar do zero.

Como é uma sessão

Quando você pede ao seu editor para "testar o fluxo de login", aqui está o que ele faz:

User: "Test the login flow"

AI calls:
  scan_codebase({ codebase_path: ".", url: "http://localhost:3000" })
    -> Finds /login route, LoginForm component, POST /api/auth/login endpoint
    -> Returns 8 generated test scenarios

  get_context({ feature: "login" })
    -> Returns src/app/login/page.tsx (has name="email", name="password" fields)
    -> Returns src/app/api/auth/login/route.ts (POST handler, returns { token })
    -> AI now knows the real selectors: [name='email'], [name='password']

  login({ email: "test@example.com", password: "pass123" })
    -> Opens Chromium, fills the form, clicks submit
    -> Returns: { success: true, final_url: "/dashboard", tokens_found: 2 }
    -> Returns screenshot of post-login dashboard

  execute_scenario({ scenario: { name: "Login with invalid password", ... } })
    -> Returns screenshot showing error state

  generate_report()
    -> Writes .vibe/report.html, opens in browser

AI reports: "Login works. Invalid password shows an error. All 3 login scenarios passed."

FAQ

O vibe-testing usa um LLM internamente? Não. Ele usa verificação heurística (mudanças de URL, detecção de toast, erros de API). O modelo do seu editor é o cérebro: ele vê capturas de tela e decide o que testar em seguida. As execuções não têm custo de API.

Qual é a diferença entre explore_page e execute_scenario? explore_page é amplo: clica em cada botão e campo de entrada que encontra e relata os resultados. execute_scenario é preciso: você fornece etapas específicas e ele as segue exatamente. Use explore_page para descobrir o que há em uma página e depois execute_scenario para testar fluxos específicos.

Para que serve get_context? Ele retorna o código-fonte real de um recurso, para que a IA saiba [name='email'] em vez de adivinhar #email-input. Sempre chame-o antes de escrever etapas de teste para um recurso específico.

Ele lida com SPAs com roteamento no lado do cliente? Sim. O Playwright navega no navegador real, então o roteamento no lado do cliente (React Router, Vue Router e outros) funciona naturalmente.

Ele lida com login/autenticação? Sim. A ferramenta login preenche credenciais em um navegador real, captura tokens de autenticação de localStorage/cookies e mantém essa sessão ativa para testes autenticados. As credenciais são persistidas em .vibe/memory/ e reutilizadas automaticamente.

Ele vai clicar em "Excluir Conta" ou outros botões destrutivos? Não. Defina never_interact em vibe.config.json ou VIBE.md para bloquear ações perigosas. Qualquer botão cujo texto ou seletor corresponda é ignorado durante a exploração.

Posso usá-lo sem um editor com IA? Sim. vibe-test run https://your-app.com executa de forma autônoma. Ele varre, gera cenários, executa-os e produz um relatório HTML sem precisar de um editor.

Como testo um ambiente de staging? Defina url em vibe.config.json para a URL do seu staging, ou passe como argumento da CLI: npx vibe-testing@latest run https://staging.myapp.com.

Funciona com monorepos? Sim. init detecta workspaces Turborepo/pnpm/yarn e encontra o aplicativo frontend automaticamente.

Requisitos

Node.js >= 20 (a suíte de testes usa vitest 4.x que requer Node 20+)
Playwright Chromium. init instala a versão correspondente. Para instalar ou reparar diretamente:
```
npx vibe-testing@latest install-browser
```

run e converge verificam o navegador antes de varrer seu projeto e imprimem o mesmo comando de recuperação quando ele está ausente.

Docker

Uma imagem Node 20 + Chromium está incluída para ambientes que preferem servidores MCP baseados em contêineres:

docker build -t vibe-test .
# wire into your editor's MCP config:
# { "command": "docker", "args": ["run", "--rm", "-i", "vibe-test"] }

Contribuindo

git clone https://github.com/AishwaryShrivastav/vibe-testing.git
cd vibe-testing
npm install
npx playwright install chromium
npm run build   # tsc -> dist/
npm run dev     # run CLI without building
npm run mcp     # run MCP server without building
npm test        # unit and isolated integration tests
VIBE_REAL_BROWSER=1 npm test  # also run real Chromium CLI/MCP regressions

Consulte CHANGELOG.md para o histórico de versões. Relatórios de bugs e solicitações de recursos: GitHub issues.

Licença

MIT, Aishwary Shrivastav

vibe-testing

Documentação

vibe-testing

O que os testes com ciência do código adicionam

Conteúdo

Como funciona

Configuração do MCP

Agent Plugin

Pacote MCPB

Opção 1: automática (recomendada)

Opção 2: manual por editor

Claude Code

Cursor

Windsurf

VS Code (GitHub Copilot)

Roo Code / Cline

A partir de build local (desenvolvimento)

Referência das ferramentas MCP

Entradas das ferramentas

Fluxo de trabalho recomendado

Sessão de teste completa

Testar um recurso específico

Verificar uma correção de bug

Encontrar o que está quebrado

Comando init

Comandos da CLI

Opções de run

Opções de converge

VIBE.md, orientação do projeto

Configuração

vibe.config.json

Frameworks suportados

Memória e detecção de regressões

Como é uma sessão

FAQ

Requisitos

Docker

Contribuindo

Licença

Links

Opções de `run`

Opções de `converge`