Test Results
Affichez l’exécution des tests d’un agent en direct. Les tests arrivent dans leurs fichiers, puis se replient en « 118 passed, 2 failed in 4.2s » avec chaque échec toujours ouvert. Diffs Expected et Received au mot près, délais dépassés et snapshots, stacks de Stack Trace, filtres, relance des échecs et demande de correction, plus des adaptateurs pour Vitest, Jest, Playwright et pytest.
Quand un agent lance vos tests, le chat devrait montrer ce qu’un développeur cherche : où il en est, ce qui a échoué et pourquoi. Pendant l’exécution, Test Results affiche une ligne en direct « Running tests · 42 of 120 » avec des compteurs qui défilent chiffre par chiffre et une barre partagée entre réussis, échoués et ignorés. Les tests arrivent dans leurs fichiers à mesure qu’ils se terminent, et le fichier en cours reste ouvert.
Quand l’exécution se termine, la ligne devient un résumé au passé comme « 118 passed, 2 failed in 4.2s ». Une exécution sans échec se replie. Une exécution en échec reste ouverte, avec les fichiers réussis repliés et les fichiers en échec ouverts, sauf si vous les avez ouverts ou fermés vous-même. Chaque échec affiche son message, un diff Expected et Received au niveau des mots et son stack via Stack Trace, avec vos frames en premier et ceux du framework repliés. Les timeouts et les différences de snapshot ont leur propre formulation.
Filtrez par All, Failed, Skipped ou Slow, copiez un échec en texte, ouvrez les frames dans votre éditeur et renvoyez Ask to fix, Rerun failed, Rerun et Update snapshot à l’agent. fromVitestJson, fromJestJson, fromPlaywrightJson et fromJUnitXml transforment des rapports en exécution, et applyTestEvent assemble des événements en direct en une seule.
Procurez-vous HextaUI Pro
Un seul paiement débloque tous les blocs, y compris les prochains. Voir les tarifs.
Ajouter le registre Pro à components.json
components.json Ajouter votre token
Créez un token sur votre page de compte et placez-le dans
.env.localsous le nomHEXTAUI_PRO_TOKEN.Ajouter le block
pnpm dlx shadcn@latest add @hextaui-pro/test-results
Avec AI SDK
Faites de runTests un outil dont l’execute renvoie l’exécution après chaque événement du reporter, pour que chaque mise à jour arrive comme sortie préliminaire. Affichez-la dans un ToolCall qui reste ouvert quand des tests échouent, et renvoyez Ask to fix et Rerun failed à l’agent sous forme de messages.
Depuis un rapport enregistré
fromVitestJson et fromJestJson lisent la sortie du reporter JSON. Passez une root pour raccourcir les chemins absolus, et getEditorHref pour ouvrir les frames dans Cursor ou VS Code.
pytest et XML JUnit
fromJUnitXml lit pytest --junitxml et les autres rapports JUnit. Les classes de test deviennent des blocs describe, le code source en échec s’affiche comme du code, et Rerun failed vous donne les node ids.
Depuis vos propres événements
Envoyez des événements run-start, test-start, test-end, file-end et run-end depuis n’importe quel runner et assemblez-les avec applyTestEvent. Elle est pure, donc elle fonctionne dans un reducer, un store ou sur le serveur.
Anatomie
Les parties à composer, de l’extérieur vers l’intérieur.
| Partie | Description |
|---|---|
TestResults | L’exécution : en-tête en direct, progression, filtre, actions et fichiers. |
ValueDiff | Expected et Received, avec les mots modifiés marqués. |
applyTestEvent, createTestRun | Des fonctions pures qui construisent une exécution à partir d’événements en streaming. |
fromVitestJson, fromJestJson, fromPlaywrightJson, fromJUnitXml | Des adaptateurs qui transforment la sortie d’un reporter en exécution. |
summarizeRun, formatFailures | La ligne de résumé, et les échecs en texte brut pour un prompt ou le presse-papiers. |
TestResults
Accepte aussi toutes les props de section sauf children.
| Prop | Type | Par défaut |
|---|---|---|
runL’exécution, venant d’un adaptateur, d’applyTestEvent ou de vos propres données. | TestRun | – |
titleLe libellé en direct pendant que les tests tournent. | string | "Running tests" |
labelNom accessible de la région. | string | "Test results" |
slowThresholdLes tests qui prennent au moins ce nombre de millisecondes sont considérés comme lents. | number | 300 |
rootRacine du projet, retirée des chemins dans les stacks. | string | – |
defaultOpenForce l’ouverture ou non de l’exécution. Par défaut, elle reste ouverte pendant qu’elle tourne et quand quelque chose a échoué. | boolean | – |
defaultFilterLe filtre de départ. | "all" | "failed" | "skipped" | "slow" | "all" |
onAskToFixAffiche Ask to fix sur l’exécution et sur chaque échec. | (failed: FailedTest[]) => void | – |
onRerunFailedAffiche Rerun failed quand l’exécution se termine avec des échecs. | (failed: FailedTest[]) => void | – |
onRerunTestAffiche Rerun sur chaque échec. | (failed: FailedTest) => void | – |
onUpdateSnapshotAffiche Update snapshot sur les différences de snapshot. | (failed: FailedTest) => void | – |
getFrameHrefTransforme les frames du stack en liens, par exemple avec getEditorHref. | (frame: StackFrame) => string | undefined | – |
onFrameClickAppelée quand on clique sur un frame. | (frame: StackFrame, event: MouseEvent) => void | – |
| Prop | Type | Par défaut |
|---|---|---|
statusSi des tests tournent encore. | "running" | "done" | "cancelled" | – |
filesLes fichiers dans l’ordre où ils ont démarré, chacun avec ses tests, sa durée et une erreur s’il n’a pas pu se charger. | TestFile[] | – |
totalLe nombre de tests attendus, pour « 42 of 120 ». Par défaut, les totaux collectés par fichier. | number | – |
durationMillisecondes, pour le résumé. Mesurée pendant l’exécution si elle est omise. | number | – |
startedAtLe moment où l’exécution a démarré, en timestamp, pour le minuteur en direct. | number | – |
| Prop | Type | Par défaut |
|---|---|---|
nameLe nom propre du test. | string | – |
suiteBlocs describe englobants, du plus externe au plus interne. | string[] | – |
statusL’état du test. | "queued" | "running" | "passed" | "failed" | "skipped" | "todo" | – |
durationMillisecondes. | number | – |
retriesCombien de fois il a été relancé. | number | – |
failurePourquoi il a échoué. | TestFailure | – |
| Prop | Type | Par défaut |
|---|---|---|
kindChoisit la formulation, comme « Timed out after 5s » ou « Snapshot mismatch ». | "assertion" | "snapshot" | "timeout" | "error" | – |
messageLe message de l’assertion, sans les lignes Expected et Received. | string | – |
expected, receivedLes deux côtés de la comparaison, lus dans l’erreur, un diff ou le message. | string | – |
stackTexte pour parseStackTrace. Absent quand il n’y a pas de frames. | string | – |
detailsSortie supplémentaire, comme le code source en échec de pytest. | string | – |
rawLe texte d’origine, utilisé par Copy. | string | – |
applyTestEvent(run, event)
Renvoie une nouvelle exécution. createTestRun() en donne une vide pour commencer.
| Prop | Type | Par défaut |
|---|---|---|
eventL’un de run-start, file-start, test-start, test-end, file-end et run-end. Les tests sont reconnus par id, ou par fichier, suite et nom. | TestEvent | – |
event.errorUne chaîne, ou un objet avec message, stack, expected, actual et diff, comme le TestError de Vitest. | TestErrorInput | – |
fromVitestJson(report, options)
fromJestJson prend le même rapport. fromPlaywrightJson lit le reporter JSON de Playwright, et fromJUnitXml(xml, options) lit le XML JUnit.
| Prop | Type | Par défaut |
|---|---|---|
options.rootRacine du projet à retirer des chemins de fichiers. Sans elle, les chemins commencent au premier dossier comme src ou tests. | string | – |
| Touche | Action |
|---|---|
| Tab | Parcourt l’en-tête de l’exécution, le filtre, les actions, chaque fichier et chaque test en échec. |
| EnterSpace | Ouvre ou ferme l’exécution, un fichier ou un échec. |
| ←→ | Passe d’un filtre à l’autre. |
- L’exécution est une région nommée avec aria-busy pendant que les tests tournent. Une région live polie annonce le résumé final une seule fois, pour que les tests qui arrivent et les compteurs qui défilent restent silencieux.
- L’en-tête de l’exécution, chaque fichier et chaque test en échec sont des boutons de divulgation avec aria-expanded. Leur nom lit le résumé, les totaux du fichier, ou le statut et le nom du test.
- Le filtre est un groupe de toggles. Les flèches passent d’une option à l’autre, et les filtres vides sont désactivés.
- Le statut ne repose jamais sur la couleur seule : chaque état a sa propre marque, les lecteurs d’écran entendent « Passed » ou « Failed » avant chaque test, Expected et Received sont étiquetés, et les mots modifiés sont soulignés en couleurs forcées. Avec le mouvement réduit, les lignes et les marques apparaissent sans glisser.
Construit avec
Les composants HextaUI gratuits dont Test Results est constitué. Chacun s’installe séparément.
Code
7 fichiers, ajoutés à components/blocks/test-results.