Test Results
Zeig den Testlauf eines Agents, während er läuft. Tests strömen in ihre Dateien und klappen dann zu „118 passed, 2 failed in 4.2s“ ein, wobei jeder Fehler offen bleibt. Expected- und Received-Diffs auf Wortebene, Timeouts und Snapshots, Stacks aus Stack Trace, Filter, Fehlgeschlagene erneut ausführen und Beheben lassen, dazu Adapter für Vitest, Jest, Playwright und pytest.
Wenn ein Agent deine Tests ausführt, sollte der Chat zeigen, worauf ein Entwickler achtet: wie weit er ist, was fehlgeschlagen ist und warum. Während Tests laufen, zeigt Test Results eine Live-Zeile „Running tests · 42 of 120“ mit Zahlen, die Ziffer für Ziffer weiterticken, und einem Balken, der in bestanden, fehlgeschlagen und übersprungen aufgeteilt ist. Tests strömen in ihre Dateien, sobald sie fertig sind, und die laufende Datei bleibt geöffnet.
Wenn der Lauf endet, wird die Zeile zu einer Zusammenfassung in der Vergangenheit wie „118 passed, 2 failed in 4.2s“. Ein sauberer Lauf klappt ein. Ein fehlgeschlagener bleibt offen, mit eingeklappten bestandenen und geöffneten fehlgeschlagenen Dateien, außer du hast sie selbst geöffnet oder geschlossen. Jeder Fehler zeigt seine Meldung, einen Diff von Expected und Received auf Wortebene und seinen Stack über Stack Trace, mit deinen Frames zuerst und eingeklappten Framework-Frames. Timeouts und Snapshot-Abweichungen bekommen eigene Formulierungen.
Filtere nach All, Failed, Skipped oder Slow, kopiere einen Fehler als Text, öffne Frames in deinem Editor und schicke Ask to fix, Rerun failed, Rerun und Update snapshot an den Agenten zurück. fromVitestJson, fromJestJson, fromPlaywrightJson und fromJUnitXml machen aus Reports einen Lauf, und applyTestEvent fügt Live-Events zu einem zusammen.
HextaUI Pro holen
Eine einmalige Zahlung schaltet jeden Block frei, auch künftige. Preise ansehen.
Die Pro-Registry zu components.json hinzufügen
components.json Token hinzufügen
Erstelle auf deiner Kontoseite einen Token und trage ihn in
.env.localalsHEXTAUI_PRO_TOKENein.Den Block hinzufügen
pnpm dlx shadcn@latest add @hextaui-pro/test-results
Mit dem AI SDK
Mach runTests zu einem Tool, dessen execute den Lauf nach jedem Reporter-Event liefert, sodass jedes Update als vorläufige Ausgabe ankommt. Rendere ihn in einem ToolCall, der offen bleibt, wenn Tests fehlschlagen, und schicke Ask to fix und Rerun failed als Nachrichten an den Agenten zurück.
Aus einem gespeicherten Report
fromVitestJson und fromJestJson lesen die Ausgabe des JSON-Reporters. Übergib eine root, um absolute Pfade zu kürzen, und getEditorHref, um Frames in Cursor oder VS Code zu öffnen.
pytest und JUnit-XML
fromJUnitXml liest pytest --junitxml und andere JUnit-Reports. Testklassen werden zu describe-Blöcken, der fehlschlagende Quelltext erscheint als Code, und Rerun failed liefert dir die Node-IDs.
Aus deinen eigenen Events
Sende run-start-, test-start-, test-end-, file-end- und run-end-Events von einem beliebigen Runner und füge sie mit applyTestEvent zusammen. Die Funktion ist rein und funktioniert daher in einem Reducer, einem Store oder auf dem Server.
Aufbau
Die Teile, die du zusammensetzt, von außen nach innen.
| Part | Beschreibung |
|---|---|
TestResults | Der Lauf: Live-Kopf, Fortschritt, Filter, Aktionen und Dateien. |
ValueDiff | Expected und Received, mit markierten geänderten Wörtern. |
applyTestEvent, createTestRun | Reine Helfer, die aus gestreamten Events einen Lauf bauen. |
fromVitestJson, fromJestJson, fromPlaywrightJson, fromJUnitXml | Adapter, die Reporter-Ausgaben in einen Lauf umwandeln. |
summarizeRun, formatFailures | Die Zusammenfassungszeile und Fehler als einfacher Text für einen Prompt oder die Zwischenablage. |
TestResults
Akzeptiert außerdem alle section-Props außer children.
| Prop | Typ | Standard |
|---|---|---|
runDer Lauf, aus einem Adapter, applyTestEvent oder deinen eigenen Daten. | TestRun | – |
titleDas Live-Label, während Tests laufen. | string | "Running tests" |
labelZugänglicher Name der Region. | string | "Test results" |
slowThresholdTests, die mindestens so viele Millisekunden dauern, gelten als langsam. | number | 300 |
rootProjektwurzel, die aus Pfaden in Stacks entfernt wird. | string | – |
defaultOpenÜberschreibt, ob der Lauf geöffnet ist. Standardmäßig bleibt er offen, solange er läuft und wenn etwas fehlgeschlagen ist. | boolean | – |
defaultFilterDer Filter, mit dem er startet. | "all" | "failed" | "skipped" | "slow" | "all" |
onAskToFixZeigt Ask to fix am Lauf und an jedem Fehler. | (failed: FailedTest[]) => void | – |
onRerunFailedZeigt Rerun failed, sobald der Lauf mit Fehlern endet. | (failed: FailedTest[]) => void | – |
onRerunTestZeigt Rerun an jedem Fehler. | (failed: FailedTest) => void | – |
onUpdateSnapshotZeigt Update snapshot bei Snapshot-Abweichungen. | (failed: FailedTest) => void | – |
getFrameHrefMacht Stack-Frames zu Links, zum Beispiel mit getEditorHref. | (frame: StackFrame) => string | undefined | – |
onFrameClickWird aufgerufen, wenn ein Frame angeklickt wird. | (frame: StackFrame, event: MouseEvent) => void | – |
| Prop | Typ | Standard |
|---|---|---|
statusOb noch Tests laufen. | "running" | "done" | "cancelled" | – |
filesDateien in der Reihenfolge, in der sie gestartet sind, jeweils mit Tests, Dauer und einem Fehler, falls sie nicht geladen werden konnten. | TestFile[] | – |
totalWie viele Tests zu erwarten sind, für „42 of 120“. Standardmäßig die pro Datei gesammelten Zahlen. | number | – |
durationMillisekunden, für die Zusammenfassung. Wird während des Laufs gemessen, wenn nicht angegeben. | number | – |
startedAtWann der Lauf gestartet ist, als Zeitstempel, für den Live-Timer. | number | – |
| Prop | Typ | Standard |
|---|---|---|
nameDer eigene Name des Tests. | string | – |
suiteUmschließende describe-Blöcke, der äußerste zuerst. | string[] | – |
statusDer Zustand des Tests. | "queued" | "running" | "passed" | "failed" | "skipped" | "todo" | – |
durationMillisekunden. | number | – |
retriesWie oft er wiederholt wurde. | number | – |
failureWarum er fehlgeschlagen ist. | TestFailure | – |
| Prop | Typ | Standard |
|---|---|---|
kindBestimmt die Formulierung, etwa „Timed out after 5s“ oder „Snapshot mismatch“. | "assertion" | "snapshot" | "timeout" | "error" | – |
messageDie Assertion-Meldung, ohne die Zeilen Expected und Received. | string | – |
expected, receivedBeide Seiten des Vergleichs, gelesen aus dem Fehler, einem Diff oder der Meldung. | string | – |
stackText für parseStackTrace. Fehlt, wenn es keine Frames gibt. | string | – |
detailsZusätzliche Ausgabe, etwa der fehlschlagende Quelltext von pytest. | string | – |
rawDer Originaltext, den Copy verwendet. | string | – |
applyTestEvent(run, event)
Gibt einen neuen Lauf zurück. createTestRun() liefert einen leeren zum Start.
| Prop | Typ | Standard |
|---|---|---|
eventEines von run-start, file-start, test-start, test-end, file-end und run-end. Tests werden über die id zugeordnet, oder über Datei, Suite und Namen. | TestEvent | – |
event.errorEin String oder ein Objekt mit message, stack, expected, actual und diff, wie Vitests TestError. | TestErrorInput | – |
fromVitestJson(report, options)
fromJestJson nimmt denselben Report. fromPlaywrightJson liest Playwrights JSON-Reporter, und fromJUnitXml(xml, options) liest JUnit-XML.
| Prop | Typ | Standard |
|---|---|---|
options.rootProjektwurzel, die aus Dateipfaden entfernt wird. Ohne sie beginnen Pfade beim ersten Ordner wie src oder tests. | string | – |
| Taste | Aktion |
|---|---|
| Tab | Springt durch den Lauf-Kopf, den Filter, die Aktionen, jede Datei und jeden fehlgeschlagenen Test. |
| EnterSpace | Öffnet oder schließt den Lauf, eine Datei oder einen Fehler. |
| ←→ | Wechselt zwischen den Filtern. |
- Der Lauf ist eine beschriftete Region mit aria-busy, solange Tests laufen. Eine höfliche Live-Region sagt die abschließende Zusammenfassung einmal an, sodass gestreamte Tests und tickende Zahlen still bleiben.
- Der Lauf-Kopf, jede Datei und jeder fehlgeschlagene Test sind Disclosure-Buttons mit aria-expanded. Ihre Namen lesen die Zusammenfassung, die Zahlen der Datei oder Status und Namen des Tests vor.
- Der Filter ist eine Toggle-Gruppe. Pfeiltasten wechseln zwischen den Optionen, und Filter ohne Inhalt sind deaktiviert.
- Status ist nie nur Farbe: Jeder Zustand hat sein eigenes Zeichen, Screenreader hören „Passed“ oder „Failed“ vor jedem Test, Expected und Received sind beschriftet, und geänderte Wörter werden in erzwungenen Farben unterstrichen. Bei reduzierter Bewegung erscheinen Zeilen und Zeichen ohne Gleiten.
Gebaut mit
Die kostenlosen HextaUI-Komponenten, aus denen Test Results besteht. Jede lässt sich einzeln installieren.
Code
7 Dateien, hinzugefügt zu components/blocks/test-results.