Produkt · Automatisierte Tests
Das Spiel ist getestet, bevor du es spielst.
EvonX teilt jede Änderung an einem Spiel in Schritte auf und prüft jeden Schritt vor dem nächsten. Wenn du die Vorschau spielst, ist dieser Build schon getestet.
Ein Test nach jedem Schritt
Jeder Schritt des Plans ist ein Aktionsknoten mit eigener Prüfung. Der Agent baut erst auf einem Schritt weiter, wenn feststeht, dass er funktioniert.
Fehler behoben, bevor du sie siehst
Schlägt eine Prüfung fehl, findet der Agent die Ursache und repariert sie im selben Schritt. Du spielst einen Build, der seine Prüfungen schon bestanden hat.
Geprüft in einer echten Umgebung
Die Tests laufen in der Live-Vorschau – einem echten Container mit dem echten Spiel –, nicht gegen Mocks, die grün sind, während die Produktion kaputtgeht.
Regressionen vor dem PR erkannt
Weil die Prüfung während des Builds laufend passiert, fallen Regressionen auf, solange sie einen Schritt tief sind – nicht erst, wenn sie unter einer Woche voller Änderungen begraben liegen.
Was der Ausführungsgraph zeigt
Ein Lauf ist ein Graph aus Aktionsknoten, und die Pfeile sind echte Abhängigkeiten statt einer To-do-Reihenfolge. Hier sind das Datenmodell und die Persistenzschicht grün – genau das hat die Admin-Screens freigegeben, mit dem Bau zu beginnen; der mobile Ablauf dahinter wartet in der Warteschlange, und der unterste Knoten – Grenzfall- und Regressionstests – bleibt gelb, bis beide Zweige fertig sind, denn bis dahin gibt es nichts Sinnvolles, wogegen man auf Regressionen prüfen könnte. Die Zähler oben fassen den Lauf in einer Zeile zusammen: wie viele Knoten es gibt, wie viele fertig sind, wie viele laufen und wie viele fehlgeschlagen sind.
Testen als Teil des Bauens, nicht als Phase danach
In den meisten Teams ist Testen eine Phase, die beginnt, wenn die Entwicklung endet – genau dann, wenn Fehler am teuersten zurückzubauen sind. EvonX dreht das um: Die Prüfung steckt in jedem Aktionsknoten, sodass Qualität Schritt für Schritt durchgesetzt wird, solange die Änderung noch günstig zu korrigieren ist.
Erst der Beweis, dann die Freigabe
Das Ergebnis ist eine Live-Vorschau, die du spielen kannst. Du gibst einen spielbaren Build mit bestandenen Prüfungen frei, und erst dann wird die Änderung zu einem Pull Request. Der Graph im Screenshot zeigt die Knoten, die ein Spiel-Build durchläuft.
Spiel einen Build, der schon getestet ist.
Starte kostenlos. Beschreib ein Spiel und sieh zu, wie jeder Schritt gebaut und geprüft wird.