Manche Testpläne sind kaputt, bevor sie je laufen.
Ein fehlerhafter Schritt oder ein undefinierter Selektor schlägt nicht sauber fehl – er verschwendet einen Lauf, nur um das herauszufinden. testsprite test lint <planFile> prüft zuerst die Struktur eines Testplans, sodass Sie das Problem erkennen, bevor Sie Zeit oder Credits dafür aufwenden.
Teil derselben CLI, die Sie bereits nutzen
Fehlerhafte Schritte erkennen
testsprite test lint <planFile> prüft jeden Action- und Assertion-Schritt eines Testplans auf strukturelle Probleme – bevor einer davon gegen Ihre Live-Umgebung läuft.
Mehrdeutige Assertions markieren
Eine Assertion ohne klares Ziel ist ein Problem, das Sie nicht mitten im Lauf entdecken wollen. Lint erkennt es, während der Plan noch eine reine JSON-Datei ist.
Fehlende Selektoren aufspüren
Ein Schritt, der auf einen im Plan nie definierten Selektor verweist, wird sofort markiert – statt später als verwirrender Fehlschlag aufzutauchen.
Funktioniert mit jedem Testplan
Lint läuft auf jeder Testplan-JSON-Datei – ob von TestSprite generiert oder von Hand bearbeitet –, sodass es sich unabhängig davon einfügt, wie Ihre Pläne tatsächlich entstehen.
$ testsprite test lint test-plan.json
Checking test-plan.json for structural problems...
✗ 2 issues found
- step 3: assertion is missing a clear target
- step 7: selector not defined in this plan
→ fix these before running the plan
$ testsprite test lint test-plan.json
Checking test-plan.json for structural problems...
✓ no structural problems found
Verschwenden Sie keinen Lauf an einen Plan, der nie funktioniert hätte
Ein Testplan mit einem fehlerhaften Schritt oder einem undefinierten Selektor scheitert nicht, weil Ihr Produkt kaputt ist – er scheitert, weil der Plan selbst ein strukturelles Problem hat. Linting erkennt das im Voraus, bevor es Sie einen Lauf kostet.
Gebaut für Testpläne, die von Hand bearbeitet werden
Funktioniert mit jedem Testplan
Generiert, bearbeitet, egal – test lint läuft auf jeder Testplan-JSON-Datei in Ihrem Projekt.
Fließt zurück in den Loop
Ein Agent, der einen Testplan generiert oder bearbeitet, kann test lint aufrufen, bevor er ihn an test run übergibt – so werden Probleme erkannt, solange sie noch billig zu beheben sind.
Kostenlose Community-Version
Bietet eine kostenlose Community-Version, die uns für jeden zugänglich macht.
Kombinierbar mit dem Testlauf
Führen Sie testsprite test lint direkt vor testsprite test run aus, damit ein strukturelles Problem niemals die Chance bekommt, einen echten Lauf zu verbrennen.
Weltweit von Unternehmen geschätzt
"TestSprite bietet eine umfangreiche Testfallgenerierung, eine klare Struktur und leicht lesbaren Code. Es unterstützt auch einfaches Online-Debugging mit der Möglichkeit, schnell durch die Generierung neuer Testfälle zu erweitern."
"Die Automatisierung von TestSprite hilft uns, Tonnen manueller Arbeit zu reduzieren. Die Entwickler können Fehler im Entwicklungsprozess leichter und früher erkennen und beheben."
FAQ
Was prüft testsprite test lint genau?
Es prüft die Struktur einer Testplan-JSON-Datei – etwa fehlerhafte Action- oder Assertion-Schritte, Assertions ohne klares Ziel und referenzierte, aber nie definierte Selektoren –, bevor der Plan gegen Ihre Live-Umgebung läuft.
Was unterscheidet das davon, den Testplan einfach auszuführen und zu sehen, was passiert?
Den Plan auszuführen kostet Zeit und Credits, nur um herauszufinden, dass der Plan selbst kaputt war. Linting findet dieselben strukturellen Probleme allein aus der JSON-Datei, bevor überhaupt etwas ausgeführt wird.
Funktioniert das auch bei Testplänen, die ich selbst geschrieben oder von Hand bearbeitet habe, nicht nur bei generierten?
Ja – test lint läuft auf jeder Testplan-JSON-Datei, egal ob sie von TestSprite stammt oder direkt bearbeitet wurde.
Was mache ich, wenn test lint ein Problem findet?
Beheben Sie den markierten Schritt in der Testplan-JSON-Datei und führen Sie test lint erneut aus. Ein sauberer Durchlauf bedeutet, dass der Plan strukturell in Ordnung ist, bevor Sie einen Lauf dafür aufwenden.
Sollte ich test lint jedes Mal ausführen, auch bei Plänen, die ich schon zuvor ausgeführt habe?
Es ist günstig auszuführen und erkennt Probleme, die durch manuelle Bearbeitungen entstanden sind – es vor test run auszuführen, ist daher eine sinnvolle Gewohnheit, besonders in CI.