Automatisierte Tests in der Realität?
Ich lerne immer mal wieder etwas programmieren und beschäftige mich gerade mit automatisierten Tests.
Bei Klassen, die die Logik der Software enthalten komme ich damit auch relativ gut zurecht und da finde ich die auch sehr sinnvoll.
Aber es gibt auch Tests mit denen man das Verhalten der Webseite beim aufrufen testet. Und das finde ich bei richtigen Webseiten (wo man nicht nur die Ausgabe von einer API testet) sehr kompliziert und irgendwie auch fehleranfällig. Teilweise gehen die ja schon kaputt, wenn man ne Kleinigkeit am Aufbau ändert, obwohl noch alles funktioniert wie es soll.
Werden die wirklich in der Realität so verwendet in Unternehmen? Oder wird da nur die interne Logik getestet (und höchstens, ob die einzelnen Seiten ohne Fehler aufgerufen werden können)?
4 Antworten
Was du beschreibst hört sich sehr nach End to End Tests an.
Ich denke es gibt da ein paar Dinge zu beachten:
- Unit Tests vs End to End Tests. Mit entsprechenden Frameworks oder Libraries ist es auch möglich, einzelne Frontend Komponenten zu unit testen. Dann hast du nur diese Komponente in einer isolierten Testumgebung, und das funktioniert schon mal wesentlich besser.
- End to End Tests lohnen sich für sehr wichtige Dinge, oder wie du schon sagst vielleicht für smoke test. Sind definitiv langsamer und komplexer. Aber es gibt defintiv Fälle, in denen Komponenten einzeln scheinbar richtig funktionieren, aber dann zusammen für Fehler Sorgen.
- Test & Aufbau der Komponenten. So etwas wie den 5. Button auf der Page zu nehmen ist natürlich Quatsch. Mit gutem Naming und Selektoren sollte das schon einigermaßen gut funktionieren, selbst wenn sich der Aufbau ändert. Wenn man gar keine guten Selektoren hat, muss man notfalls fürs Testing extra Attribute auf die Elemente packen.
PS: Integration Tests habe ich mal ausgelassen, ich denke für die Antwort wäre das nicht wirklich relevant, ist noch eine zwischen Stufe zwischen Unit Tests und e2e Tests.
Natürlich wird das getestet, aber eben nicht im Rahmen der Unit Tests, sondern mit Frameworks wie Selenium Webdriver.
Du redest von Frontend-Tests?
Auch das gibt es, allerdings ist es sehr von den verwendeten Technologien abhängig.
Wir arbeiten mit Blazor und implementieren Frontend-Tests mit BUnit oder Playwright.
BUnit ist (der Name deutet es an) eine Art UnitTest-Support für einzelne Blazor-Komponenten, es "rendert" (es tut so, als würde es rendern) die Komponenten ohne echte Darstellung und prüft anschließend das Ergebnis. Das ist schnell und einfach, braucht aber auch geeignete Komponenten-Architekturen - analog UnitTests.
Mit Playwright hosten wir im Grunde die komplette Website inkl. Datenbank in versteckten Browser und können einzelne Komponenten anklicken, abrufen, prüfen, etc. Das ist langsam und fordert mehr Infrastruktur, ist aber mehr eine Art E2E (Ende-zu-Ende) Test.
In der Regel sollte man aber versuchen, möglichst nahe an (B)UnitTests zu bleiben, da es viel einfacher und schneller aufgebaut ist. Automatische Tests bringen nichts, wenn man sich bei jeder Gelegenheit davor drückt, Tests zu schreiben, zu aktualisieren oder sie auszuführen. (B)UnitTests sind dagegen sehr schnell geschrieben und erweitert und können auch die Funktion überprüfen, noch bevor das restliche Programm fertig ist, sie können also während der normalen Entwicklung gepflegt werden, während E2E-Tests erst hinterher möglich sind und meistens schleifen gelassen werden.
Und wenn Du komplexere Frontend-Logik hast, ist es ggf. auch gut möglich, eben diese Logik losgelöst vom eigentlichen Frontend auszulagern und gesondert zu testen.
Ich kann nur aus der Erfahrung von zwei Projekten in einem Beratungsunternehmen berichten.
Ja, diese GUI Oberflächentests sind verdammt aufwändig und nervig anzulegen sowie zu pflegen. Diese wurden in meiner Erfahrung meist nur wenig und ungern gepflegt. Besonders, wenn die GUI noch in Entwicklung ist.
Bei uns hatte auch der Kunde nur begrenzt Interesse daran, das zu priorisieren und Aufwände dafür zu bezahlen, besonders nach der Inbetriebnahme (als die GUI dann fertig war)
Die Qualitätsgates sind alle für interne Unittests etc.
Eigentlich wäre es gut diese zu pflegen und wenn diese gut gemacht sind, sind diese ein guter Indikator für Fehler, die sich in der Entwicklung auch z.B. im Backend einschleichen. Leider habe ich noch keine API gehabt, welche leicht zu entwickeln und pflegen wäre.