Als wir vor 7 Jahren mit Test Automation für unsere Spiele angefangen haben, gab es keine Lösung, die mit unseren verwendeten Technologien funktioniert hat. Daher haben wir ein eigenes Framework entwickelt, was bisher auch sehr gut funktioniert.
Es ist nicht unmöglich Tests zu schreiben und mit guter Übung kann man auch ziemlich effizient sein. Aber für neue Leute, die Tests schreiben wollen oder das nicht tagtäglich machen, ist die Lernkurve relativ hoch. Daher wollen wir das vereinfachen.
Ja, das wäre schön und darum liegt die Idee bei uns auch schon seit ein paar Jahren im Backlog.
Die Regressionstests, die hinterher in die Testsuite eingefügt werden, müssen einen höheren Standard an Wiederverwendetbarkeit, Robustheit, etc. erfüllen, da hier der Spielstand fest vorgegeben sein muss. Für die Tests, die aufgenommen und gespeichert werden können, liegt der Fokus auf Schnelligkeit, so dass man Tests während der Entwicklung nutzen kann, um Änderungen fix zu testen, aber nicht immer ist es praktikabel diese Tests als Regressionstests zu übernehmen. Wenn z.B. Game-Design viele Änderungen am Balancing macht, können sie sich einen oder mehrere Tests anlegen, um zu prüfen, das ein bestimmter Bereich immer noch spielbar ist oder eben nicht. Aber es ist nicht immer notwendig, das als Regressionstests zu haben am Ende.
Nur der Entwurf der UI findet vorher statt, wie das Design sein soll, wo sich welche Buttons befinden sollen, etc. Die tatsächliche Implementierung ist der erste Punkt nach der Einrichtung des Projektes.