Arrêtez d'extraire les résultats de test de la sortie terminal.
Chaque commande testsprite accepte --output json, qui remplace le rapport terminal lisible par un humain par une sortie structurée et analysable — pour que votre tableau de bord, votre bot Slack ou votre script CI reçoive des données propres au lieu d'un mur de texte à découper avec des regex.
Intégré au même CLI que vous utilisez déjà
--output json transforme chaque commande en données auxquelles vous pouvez réellement faire confiance.Un indicateur, toutes les commandes
--output json est un indicateur global — utilisez-le avec test run, test get, test list, ou presque n'importe quelle autre commande, et obtenez la même structure en retour au lieu d'un format texte différent à chaque fois.
Conçu pour les pipelines, pas pour les yeux
Une sortie structurée signifie qu'un script CI peut vérifier un champ et décider programmatiquement de la suite, au lieu de faire un grep sur une phrase qui pourrait changer entre les versions du CLI.
Alimentez votre propre tableau de bord
Transmettez les résultats de --output json vers ce que vous utilisez déjà pour suivre les builds — un bot Slack, un tableau de bord interne, un outil d'incident — sans maintenir un extracteur de texte.
Prévisualisez avant de vous engager
Associez --output json à --dry-run pour voir exactement ce qu'une commande retournerait avant qu'elle ne s'exécute réellement.
$ testsprite test get TC_checkout_promo ...formatted, human-readable report printed to the terminal... $ testsprite test get TC_checkout_promo --output json ...the same result, returned as structured JSON on stdout... → pipe it straight into a script, a dashboard, or a Slack bot
Ne construisez pas un extracteur de texte quand JSON existe déjà
Les équipes qui ont besoin que la CI réagisse aux résultats finissent généralement par écrire des regex contre du texte terminal coloré — fragile, et ça casse dès que le formatage du CLI change. --output json vous donne les mêmes données sous une forme structurée et stable à la place.
Conçu pour les scripts, pas seulement les terminaux
Fonctionne dans tout le CLI
--output json est disponible sur la plupart des commandes testsprite, vous n'avez donc pas besoin d'une approche d'intégration différente pour chacune.
S'intègre à n'importe quel script CI
La sortie structurée est facile à analyser depuis GitHub Actions, GitLab CI, ou toute étape de pipeline, pour que vous puissiez conditionner un build sur le résultat réel plutôt que sur une correspondance de chaîne.
Version communautaire gratuite
Propose une version communautaire gratuite, pour rester accessible à tous.
Se combine avec une configuration non interactive
Combinez --output json avec testsprite setup --from-env --yes --agent <name> pour un job CI qui installe, configure et rapporte sans intervention humaine.
Approuvé par des entreprises du monde entier
"TestSprite offre une génération de cas de test riche, une structure claire et un code facile à lire. Il prend également en charge le débogage en ligne simple avec la possibilité de s'étendre rapidement en générant de nouveaux cas de test."
"L'automatisation de TestSprite nous aide à réduire des tonnes de travail manuel. Les développeurs peuvent facilement détecter et résoudre les bugs plus tôt dans le processus de développement."
FAQ
Que change réellement --output json ?
Cela fait passer la sortie d'une commande d'un texte terminal lisible par un humain à une sortie structurée et analysable sur stdout — le résultat sous-jacent est le même, simplement dans un format que vos propres outils peuvent lire.
Quelles commandes prennent en charge --output json ?
C'est un indicateur global disponible sur la plupart des commandes testsprite, pas un mode spécial intégré à une seule d'entre elles.
Puis-je utiliser cela pour alimenter un bot Slack ou un tableau de bord interne ?
Oui — comme la sortie est structurée, tout script capable de l'analyser peut transmettre le résultat où que votre équipe consulte déjà le statut des builds.
--output json fonctionne-t-il avec --dry-run ?
Oui — combinez-les pour voir exactement ce qu'une commande retournerait avant qu'elle ne s'exécute réellement, utile lorsque vous construisez une nouvelle intégration.
Est-ce que je n'ai cela qu'en CI, ou aussi en local ?
Le même indicateur dans les deux cas — il fonctionne de la même façon que vous exécutiez testsprite en local, dans GitHub Actions, GitLab CI, ou votre propre boucle d'agent.