Personen, die Tests schreiben sollen, d.h. Programmierer, die keine dedizierten Testautomatisierungsprogrammierer sind, aber testgetrieben (im weitesten Sinne des Wortes) arbeiten sollen, können mit diesen Instrumenten dazu gebracht werden, automatische Tests zu verwenden (zu schreiben):
Informiert über die greifbaren Vorteile, die ihr aus den automatischen Tests zieht.
-
- Sicherheit: Beim Ändern oder Refactoring von Code oder auch nur beim Implementieren von neuem Code seid ihr sicher(er) vor ungewollten Änderungen des bestehenden Verhaltens.
- Einfachheit: Ein gut gemachtes testgetriebenes Entwicklungsframework macht es für einen Entwickler einfacher und nicht schwieriger, seinen Code zu schreiben. Bei Ruby on Rails zum Beispiel, das aufgrund seiner Architektur viele verschiedene kleine Teile benötigt, um ein neues Feature zu erstellen (d.h. Controller, View, Modelle, Konfiguration, Hilfsfunktionen/Bibliotheken usw.), kann es für einen nicht so erfahrenen Programmierer leicht zu dem Effekt kommen, dass man überwältigt ist und nicht genau weiß, wo man anfangen soll, oder einfach verwirrt ist von all den kleinen Bereichen, die man anfassen muss. Wenn man zuerst mit einem Test beginnt (d.h. indem man die Route/URL, die man in einem Test implementieren soll, „besucht“), zeigen die Fehlermeldungen dem Programmierer genau jeden Schritt an, der noch fehlt.
- Integrierte Dokumentation: Insbesondere bei der Arbeit an Code von anderen Entwicklern macht es eine gut definierte Reihe automatisierter Tests einem Entwickler leicht, sich in die Materie einzuarbeiten und beispielsweise herauszufinden, welche Aktionen ein tatsächlicher Benutzer durchführen würde, um ein Ziel in der Anwendung zu erreichen.
- Wenn eure Testsuite „grün“ ist, ist das ein großer psychologischer Segen – Ihr wisst, dass ihr das System nicht kaputt gemacht habt, und es besteht kaum ein Risiko, dass ihr euch den Zorn euer Kollegen auf sich ziehen, wenn Sie als derjenige entlarvt werden, der einen wichtigen Teil des Systems kaputt gemacht und…
- Bringt ihnen bei, wie man Tests schreibt – z. B. durch regelmäßige „Brownbag“-Sitzungen oder ähnliches, bei denen ihr oder ein Kollege gute Techniken aufzeigen oder die Verwendung der Testsuite gemeinsam üben. Macht es zu einer Teamleistung.
- Erzwingt es, indem ihr erfolgreiche Tests (und Testabdeckung) in der CI/CD-Pipeline verlangt und diese Pipeline zur einzigen technischen Möglichkeit für die Bereitstellung auf den Servern machen. Dies ist eindeutig ein sekundärer Weg, um die Entwickler unter Druck zu setzen – wenn ihr die Zustimmung nicht durch eine andere vernünftige Methode erhalten könnt, ist dies eine Art letzter Versuch und kann leicht zu Abwanderung führen, weil sich Personen unter Druck gesetzt fühlen.
Für Personen, die mit der Durchführung von Tests und der Überprüfung der Ergebnisse betraut sind:
- Die positive Motivation besteht natürlich darin, sicherzustellen, dass ein Einsatz das Zielsystem nicht beschädigt. Ehrlich gesagt, wenn eine Person, die für diese Aufgabe verantwortlich ist, sich nicht um diesen Aspekt kümmert, wie in Ihrem Fall, sehe ich nicht wirklich, welche Art von „wohlwollender“ Motivation ihr anwenden könntet. Unter der Annahme, dass die Tests tatsächlich funktionieren und Fehler finden und dass die Fehler, die in der Produktionsumgebung auftauchen, in der Testsuite tatsächlich „rot“ sind, lässt sich darüber nicht streiten. Haben eigentlich gefragt, warum sie das tun? Vergessen sie es? Dauert es zu lange? Sind die Ergebnisse nicht schlüssig?
- Eine neutrale Maßnahme besteht darin, den Prozess zu vereinfachen. Wenn die Suite lange läuft, muss entweder genügend Zeit zwischen dem Ende des Entwicklungszyklus/Sprints und der Bereitstellungsfrist liegen, oder die Laufzeit muss verkürzt werden, z. B. durch Investitionen in mehr technische Ressourcen.
- Ein Zusatz zum Vorhergehenden ist, sicherzustellen, dass die Tests in CI/CD ausgeführt werden, wenn ein Entwickler etwas vorantreibt, um eine Frühwarnung zu erhalten, wenn Tests rot sind. Verlangt ihr ein grünes Testergebnis, bevor Sie Pull-Requests zusammenführen, usw.
- Schließlich könnt ihr die Durchführung der Tests und die Tatsache, dass die Tests grün sind, zu einem obligatorischen Schritt in der CI/CD-Pipeline machen und die Bereitstellung von außerhalb der CI/CD-Pipeline unmöglich machen. Dies könnte sich als sinnvoller erweisen als für die vorherige Gruppe von Entwicklern. Der Bereitstellungsprozess ist die letzte Hürde vor der Beschädigung der Produktionsserver, daher sollte die Durchführung der Tests das Standardverhalten sein, nicht etwas Optionales.
Neueste Kommentare