Votre CI sait déjà lire ce format.
Les résultats de test TestSprite peuvent être exportés en JUnit XML — le format que la plupart des systèmes CI savent déjà analyser et afficher. Pas de visualiseur séparé, pas de nouveau tableau de bord à consulter : les résultats apparaissent aux côtés de toutes les autres suites de tests que votre pipeline exécute.
Conçu pour les tableaux de bord CI que vous consultez déjà
Parle un format que la CI comprend déjà
JUnit XML est le format que la plupart des étapes de rapport de test CI analysent déjà, quel que soit le langage ou le framework qui l'a produit. Il n'y a pas de parseur personnalisé à écrire spécifiquement pour la sortie de TestSprite.
Apparaît là où l'équipe regarde déjà
Les widgets de rapport de test de Jenkins, GitLab CI, CircleCI et GitHub Actions peuvent afficher les résultats TestSprite dans le même résumé d'exécution que toute autre suite de tests de votre pipeline.
Pas de visualiseur séparé à consulter
Au lieu de vous connecter à un autre outil pour voir ce qui est passé, le nombre de réussites/échecs et le détail des échecs atterrissent dans l'exécution CI que votre équipe ouvre déjà après chaque build.
Se combine avec la sortie lisible par machine
Utilisez l'export JUnit pour les tableaux de bord CI, ou passez à --output json quand un script doit agir sur les résultats de façon programmatique à la place.
# .github/workflows/test.yml
- name: Run TestSprite tests
run: testsprite test run TC_checkout_promo
env:
TESTSPRITE_API_KEY: ${{ secrets.TESTSPRITE_API_KEY }}
- name: Publish test report
uses: dorny/test-reporter@v1
if: always()
with:
name: TestSprite Results
path: 'testsprite-results.xml'
reporter: java-junit
Arrêtez de demander à l'équipe de consulter un second tableau de bord
Un résultat de test qui vit là où votre équipe ne regarde pas déjà a tendance à être ignoré. Exporter en JUnit XML signifie que le résultat de réussite/échec de TestSprite atterrit dans le même résumé d'exécution CI que tout le reste, au lieu de demander à quiconque de changer de contexte.
Conçu pour les pipelines que vous avez déjà
Fonctionne avec ce que vous avez
N'importe quel système CI qui prend en charge JUnit XML — c'est-à-dire la plupart d'entre eux — peut afficher la sortie de TestSprite sans outillage supplémentaire ni intégration personnalisée.
S'intègre à une étape existante
Ajoutez TestSprite comme une étape de test de plus dans un pipeline qui exécute déjà des tests unitaires et d'intégration, et son rapport apparaît dans le même résumé d'exécution.
Version communautaire gratuite
Propose une version communautaire gratuite, pour rester accessible à tous.
Prévisualisez avant de le brancher
Utilisez --dry-run pour voir ce que ferait une exécution avant qu'elle ne fasse partie d'un pipeline qui s'exécute à chaque commit.
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
Qu'est-ce que JUnit XML, et pourquoi la CI s'en soucie-t-elle ?
C'est un schéma XML de longue date pour rapporter les résultats de test, né avec le framework JUnit, mais désormais analysé par la plupart des systèmes CI, quel que soit le langage ou le framework qui a réellement produit les résultats.
Ai-je besoin d'un plugin pour voir les résultats TestSprite dans mon tableau de bord CI ?
Non — les widgets de rapport de test de Jenkins, GitLab CI, CircleCI et GitHub Actions savent déjà analyser JUnit XML, donc l'export de TestSprite s'intègre à l'étape de rapport de test que vous avez déjà configurée.
L'export JUnit remplace-t-il les autres formats de sortie du CLI ?
Non — il coexiste avec --output json pour la sortie lisible par machine et la sortie terminal normale. Utilisez le format qui convient à l'outil qui le lit.
Cela fonctionne-t-il pour les exécutions de test frontend et backend ?
Oui — l'export s'applique aux résultats, qu'ils proviennent d'exécutions frontend basées sur navigateur ou d'exécutions backend/API.
Puis-je voir ce que ferait une exécution avant de la brancher dans la CI ?
Oui — --dry-run prévisualise une exécution sans l'exécuter, ce qui est utile la première fois que vous ajoutez TestSprite à un pipeline.