Test Results
Mostre a execução de testes de um agente enquanto ela acontece. Os testes chegam em seus arquivos e depois se recolhem em “118 passed, 2 failed in 4.2s” com cada falha ainda aberta. Diffs de Expected e Received por palavra, timeouts e snapshots, stacks do Stack Trace, filtros, executar falhas de novo e pedir para corrigir, além de adaptadores para Vitest, Jest, Playwright e pytest.
Quando um agente roda seus testes, o chat deveria mostrar o que um desenvolvedor procura: quanto já foi, o que falhou e por quê. Enquanto os testes rodam, Test Results mostra uma linha ao vivo “Running tests · 42 of 120” com contadores que avançam dígito a dígito e uma barra dividida em aprovados, com falha e pulados. Os testes chegam aos seus arquivos à medida que terminam, e o arquivo em andamento fica aberto.
Quando a execução termina, a linha vira um resumo no passado como “118 passed, 2 failed in 4.2s”. Uma execução limpa se recolhe. Uma com falhas fica aberta, com os arquivos aprovados recolhidos e os com falha abertos, a menos que você mesmo os tenha aberto ou fechado. Cada falha mostra sua mensagem, um diff de Expected e Received por palavra e seu stack via Stack Trace, com seus frames primeiro e os do framework recolhidos. Timeouts e divergências de snapshot têm texto próprio.
Filtre por All, Failed, Skipped ou Slow, copie uma falha como texto, abra frames no seu editor e envie Ask to fix, Rerun failed, Rerun e Update snapshot de volta ao agente. fromVitestJson, fromJestJson, fromPlaywrightJson e fromJUnitXml transformam relatórios em uma execução, e applyTestEvent junta eventos ao vivo em uma só.
Obtenha o HextaUI Pro
Um único pagamento libera todos os blocos, incluindo os futuros. Ver preços.
Adicione o registro Pro ao components.json
components.json Adicione seu token
Crie um token na sua página de conta e coloque-o em
.env.localcomoHEXTAUI_PRO_TOKEN.Adicione o bloco
pnpm dlx shadcn@latest add @hextaui-pro/test-results
Com o AI SDK
Faça de runTests uma ferramenta cujo execute entrega a execução após cada evento do reporter, para que cada atualização chegue como saída preliminar. Renderize dentro de um ToolCall que fica aberto quando testes falham, e envie Ask to fix e Rerun failed de volta ao agente como mensagens.
De um relatório salvo
fromVitestJson e fromJestJson leem a saída do reporter JSON. Passe uma root para encurtar caminhos absolutos, e getEditorHref para abrir frames no Cursor ou no VS Code.
pytest e XML do JUnit
fromJUnitXml lê pytest --junitxml e outros relatórios JUnit. Classes de teste viram blocos describe, o código que falhou aparece como código, e Rerun failed entrega os node ids.
De seus próprios eventos
Envie eventos run-start, test-start, test-end, file-end e run-end de qualquer runner e junte-os com applyTestEvent. Ela é pura, então funciona em um reducer, em um store ou no servidor.
Anatomia
As partes que você compõe, de fora para dentro.
| Parte | Descrição |
|---|---|
TestResults | A execução: cabeçalho ao vivo, progresso, filtro, ações e arquivos. |
ValueDiff | Expected e Received, com as palavras alteradas marcadas. |
applyTestEvent, createTestRun | Funções puras que montam uma execução a partir de eventos em streaming. |
fromVitestJson, fromJestJson, fromPlaywrightJson, fromJUnitXml | Adaptadores que transformam a saída de um reporter em uma execução. |
summarizeRun, formatFailures | A linha de resumo, e as falhas como texto simples para um prompt ou a área de transferência. |
TestResults
Também aceita todas as props de section, exceto children.
| Prop | Tipo | Padrão |
|---|---|---|
runA execução, de um adaptador, de applyTestEvent ou dos seus próprios dados. | TestRun | – |
titleO rótulo ao vivo enquanto os testes rodam. | string | "Running tests" |
labelNome acessível da região. | string | "Test results" |
slowThresholdTestes que levam pelo menos esse número de milissegundos contam como lentos. | number | 300 |
rootRaiz do projeto, removida dos caminhos nos stacks. | string | – |
defaultOpenSubstitui se a execução está aberta. Por padrão ela fica aberta enquanto roda e quando algo falhou. | boolean | – |
defaultFilterO filtro inicial. | "all" | "failed" | "skipped" | "slow" | "all" |
onAskToFixMostra Ask to fix na execução e em cada falha. | (failed: FailedTest[]) => void | – |
onRerunFailedMostra Rerun failed quando a execução termina com falhas. | (failed: FailedTest[]) => void | – |
onRerunTestMostra Rerun em cada falha. | (failed: FailedTest) => void | – |
onUpdateSnapshotMostra Update snapshot nas divergências de snapshot. | (failed: FailedTest) => void | – |
getFrameHrefTransforma frames do stack em links, por exemplo com getEditorHref. | (frame: StackFrame) => string | undefined | – |
onFrameClickChamada quando um frame é clicado. | (frame: StackFrame, event: MouseEvent) => void | – |
| Prop | Tipo | Padrão |
|---|---|---|
statusSe ainda há testes rodando. | "running" | "done" | "cancelled" | – |
filesArquivos na ordem em que começaram, cada um com seus testes, duração e um erro se não carregou. | TestFile[] | – |
totalQuantos testes esperar, para “42 of 120”. Por padrão, as contagens coletadas por arquivo. | number | – |
durationMilissegundos, para o resumo. Medido durante a execução quando omitido. | number | – |
startedAtQuando a execução começou, como timestamp, para o cronômetro ao vivo. | number | – |
| Prop | Tipo | Padrão |
|---|---|---|
nameO nome do próprio teste. | string | – |
suiteBlocos describe que o envolvem, do mais externo para o mais interno. | string[] | – |
statusO estado do teste. | "queued" | "running" | "passed" | "failed" | "skipped" | "todo" | – |
durationMilissegundos. | number | – |
retriesQuantas vezes ele foi repetido. | number | – |
failurePor que ele falhou. | TestFailure | – |
| Prop | Tipo | Padrão |
|---|---|---|
kindEscolhe o texto, como “Timed out after 5s” ou “Snapshot mismatch”. | "assertion" | "snapshot" | "timeout" | "error" | – |
messageA mensagem da asserção, sem as linhas Expected e Received. | string | – |
expected, receivedOs dois lados da comparação, lidos do erro, de um diff ou da mensagem. | string | – |
stackTexto para parseStackTrace. Omitido quando não há frames. | string | – |
detailsSaída extra, como o código-fonte que falhou no pytest. | string | – |
rawO texto original, usado pelo Copy. | string | – |
applyTestEvent(run, event)
Retorna uma nova execução. createTestRun() dá uma vazia para começar.
| Prop | Tipo | Padrão |
|---|---|---|
eventUm de run-start, file-start, test-start, test-end, file-end e run-end. Os testes são identificados por id, ou por arquivo, suite e nome. | TestEvent | – |
event.errorUma string, ou um objeto com message, stack, expected, actual e diff, como o TestError do Vitest. | TestErrorInput | – |
fromVitestJson(report, options)
fromJestJson recebe o mesmo relatório. fromPlaywrightJson lê o reporter JSON do Playwright, e fromJUnitXml(xml, options) lê XML do JUnit.
| Prop | Tipo | Padrão |
|---|---|---|
options.rootRaiz do projeto a remover dos caminhos de arquivo. Sem ela, os caminhos começam na primeira pasta, como src ou tests. | string | – |
| Tecla | Ação |
|---|---|
| Tab | Percorre o cabeçalho da execução, o filtro, as ações, cada arquivo e cada teste que falhou. |
| EnterSpace | Abre ou fecha a execução, um arquivo ou uma falha. |
| ←→ | Alterna entre os filtros. |
- A execução é uma região com nome e aria-busy enquanto os testes rodam. Uma região ao vivo educada anuncia o resumo final uma única vez, então testes chegando e contadores avançando ficam em silêncio.
- O cabeçalho da execução, cada arquivo e cada teste que falhou são botões de divulgação com aria-expanded. Seus nomes leem o resumo, as contagens do arquivo ou o status e o nome do teste.
- O filtro é um grupo de toggles. As setas alternam entre as opções, e filtros vazios ficam desativados.
- O status nunca é só cor: cada estado tem sua própria marca, leitores de tela ouvem “Passed” ou “Failed” antes de cada teste, Expected e Received têm rótulo e as palavras alteradas ficam sublinhadas em cores forçadas. Com movimento reduzido, linhas e marcas aparecem sem deslizar.
Construído com
Os componentes gratuitos do HextaUI de que Test Results é feito. Cada um é instalado separadamente.
Código
7 arquivos, adicionados a components/blocks/test-results.