Ein fehlgeschlagener CI-Lauf sollte nicht Ihr erster Hinweis auf eine Fehlkonfiguration sein.
Bevor Sie TestSprite in CI einbinden, führen Sie testsprite doctor aus. Es prüft, ob Ihr API-Schlüssel, der Netzwerkzugriff und die CLI-Version korrekt konfiguriert sind — damit sich ein banales Konfigurationsproblem nicht als echter Testfehler tarnt.
Integriert in dieselbe CLI, die Sie bereits verwenden
Ihren API-Schlüssel überprüfen
testsprite doctor bestätigt, dass Ihr TESTSPRITE_API_KEY gesetzt und gültig ist, bevor ein CI-Job seinen ersten Lauf an einem Authentifizierungsfehler verschwendet.
Netzwerk- und Proxy-Zugriff prüfen
Unternehmens-Proxys und abgeschottete CI-Runner können ausgehende Anfragen stillschweigend blockieren. Doctor bestätigt, dass die CLI TestSprite tatsächlich erreichen kann, bevor Sie es mitten in der Pipeline feststellen.
Ihre CLI-Version bestätigen
Eine Versionsabweichung zwischen dem Installierten und dem, was Ihre Pipeline erwartet, kann auf eine Art fehlschlagen, die wie ein Produktfehler aussieht. Doctor meldet es, bevor das passiert.
Überall ausführbar
Derselbe Check, egal ob Sie lokal einrichten, einen neuen CI-Job verkabeln oder herausfinden, warum die Pipeline eines Teammitglieds sich nicht authentifiziert.
$ testsprite doctor Checking environment... ✓ API key found and valid ✓ Network access to TestSprite confirmed ✓ CLI version up to date → environment looks good, ready to run tests $ testsprite doctor Checking environment... ✗ TESTSPRITE_API_KEY not set ✗ Network request blocked — check proxy configuration → fix these before running testsprite test run
Lassen Sie nicht CI Ihre Konfiguration für Sie debuggen
Eine Pipeline, die scheitert, bevor sie überhaupt Ihre Tests erreicht, testet nichts — sie scheitert nur laut. Wenn Sie zuerst testsprite doctor ausführen, wird aus „Warum ist CI gerade fehlgeschlagen" eine Zwei-Sekunden-Antwort.
Gebaut, um TestSprite in CI einzubinden
Führen Sie es aus, bevor Sie CI einrichten
Fügen Sie testsprite doctor als ersten Schritt in Ihrer Pipeline hinzu — direkt nach der Installation, vor testsprite setup und jedem echten Testlauf.
Ergänzt testsprite setup
Verwenden Sie testsprite setup --from-env --yes --agent <name>, um Anmeldedaten nicht-interaktiv zu konfigurieren, und führen Sie dann doctor aus, um zu bestätigen, dass sie tatsächlich funktionieren.
Kostenlos und Open Source
npm install -g @testsprite/testsprite-cli verschafft Ihnen die CLI. Sie ist Apache-2.0-lizenziert, sodass nichts einem ersten Check im Weg steht.
Maschinenlesbare Ausgabe
Übergeben Sie --output json, um Ergebnisse in einem Format zu erhalten, das Ihre Pipeline automatisch parsen und verarbeiten kann.
Weltweit von Unternehmen vertraut
„TestSprite bietet umfangreiche Testfall-Generierung, klare Struktur und gut lesbaren Code. Außerdem unterstützt es einfaches Online-Debugging mit der Möglichkeit, durch das Generieren neuer Testfälle schnell zu erweitern."
„Die Automatisierung von TestSprite hilft uns, jede Menge manuelle Arbeit einzusparen. Die Entwickler können Fehler im Entwicklungsprozess leicht früher erkennen und beheben."
FAQ
Was prüft testsprite doctor genau?
Es prüft, ob Ihr API-Schlüssel gesetzt und gültig ist, ob die CLI TestSprite über Ihr Netzwerk erreichen kann — auch über einen Proxy — und ob Ihre installierte CLI-Version aktuell ist.
Wann sollte ich es ausführen?
Direkt nach der Installation der CLI und erneut als erster Schritt in jeder neuen CI-Pipeline — vor testsprite setup oder einem echten Testlauf, damit ein Konfigurationsproblem schnell scheitert und nicht mitten in der Pipeline.
Was unterscheidet das davon, einfach einen Test auszuführen und zu sehen, was kaputtgeht?
Ein fehlgeschlagener Testlauf, der durch einen fehlenden API-Schlüssel oder eine blockierte Netzwerkanfrage verursacht wird, sieht identisch zu einem echten Produktfehler aus, bis Sie genauer hinsehen. Doctor unterscheidet „Ihre Einrichtung ist kaputt" von „Ihr Produkt ist kaputt", bevor Sie einen Lauf an der falschen Ursache verschwenden.
Funktioniert es in CI oder nur lokal?
Beides — es ist in jedem Fall derselbe Befehl. Führen Sie es lokal während der Einrichtung aus und dann erneut als CI-Schritt, damit ein Proxy- oder Anmeldedatenproblem in der Pipeline-Umgebung nicht unbemerkt bleibt.
Was, wenn ein Problem gemeldet wird?
Es zeigt Ihnen genau, was falsch ist — ein fehlender TESTSPRITE_API_KEY, ein blockierter Netzwerkpfad oder eine veraltete CLI-Version — sodass Sie genau dieses eine Problem beheben können, anstatt einen Testlauf zu debuggen, der nie eine Chance zum Starten hatte.