Test-Base-Development, wie visuelle Elemente prüfen?
-
Ich habe mir seit einigen Jahren das test getriebene Entwickeln angeeignet und hab dadurch spurbare bessere Software produziert (natürlich nur meiner Meinung nach)
Jetzt bin ich aber in der Situation, dass wir visuelle Elemente bauen. Beispielsweise eine Spline Rasterisierung oder Transformation von Texturen. Das sind Geschichten, die sich nicht mehr so gut wie Algorithmen testen lassen.Da wollte ich mal ein paar Meinung sammeln, wie es aus eurer Sicht testbar wär. Das einzig gescheite, was mir einfällt sind Screenshot-lösungen, bei denen ersteinmal die representative, visuelle Situation erstellt wird und gegen die dann später automatisiert verglichen wird. Was hier unschön ist, dass die Menge an Screenshots wohl mehrere Tausend übersteigen könnte. Wenn man den Kern von irgendwas ändert und dann auf einmal alle tausende Screenshot für die Katz sind und man wieder ein paar MT arbeit reinstecken muss, dann kriegt man sowas sehr schnell um die Ohren gehauen
-
Das Keyword dass du suchst heisst
"Functional Testing"Ich hoffe du findest etwas passendes zu deiner GUI Library...
-
Na so was, garkeine Benachrichtigung bekommen.
Functional Testing ist mir ein Begriff, allerdings finde ich nichts hilfreiches. Es geht auch um keine GUI, es gibt eine lib, die nimmt Befehle in Form von C++ Code entgegen und schmeißt Bilder raus.
Bei den functional tests, von denen ich gelesen habe, geht es eher darum, die Sequenz der GUI Operationen zu koordinieren.Der Ergebniszustand ist in der Regel immer ein Bild, da sind Screens ja angebracht, aber bei Integration is das Problem, dass integrierte Komponenten interagieren und man einzelne Komponenten wie einen Rasterizer nicht gelöst vom kompletten System testen kann, außer ich rechne manuel, wo die Punkte sein werden und prüfe so etwas, aber das ist nicht praktikabel.
Und wenn ich 100 Screens habe und beim 99. festelle, dass der Rasterizer sich komisch verhält und ich diesen fixe, so kann es sich auf alle 100 Screens auswirken