Welche Relevanz hat Unit Testing in einer Umgebung, in der häufig vorzeitige Versionen veröffentlicht werden?

In den letzten rund einem Jahr habe ich mein Team auf den Entwicklungsmodus "Release-Early-Release-Oft" (AKA: Rapid Application Development, nicht Agile) umgestellt. Weitere Informationen zum Schließen des Builds finden Sie in meiner Antwort hier: Eine einfache Möglichkeit, die Release-Qualität in der RAD-Umgebung zu verbessern

Als wir RAD einführten, waren die Leute ziemlich unabhängig und führten zuerst Unit-Tests durch. Die integrierten Tests fanden viel später statt. Es war ein natürlicher Prozess für sie ohne viel formelle Durchsetzung. Jetzt ist die Situation ganz anders:

1. Die gesamte Plattform ist gut in etablierte Builds / Releases integriert, die clientseitig ohne Hot Spots arbeiten.

2. Es kommen immer wieder neue Funktionsanforderungen, die wir schrittweise weiterentwickeln.

3. Die Gesamtdynamik des Systems ist sehr wichtig, da unabhängige Entwicklungsgruppen zwar die Prozesse richtig verfolgen, jedoch aufgrund komplizierter, nicht offensichtlicher Umstände schwerwiegende Fehler aufgetreten sind.

4. Viele Teile des Systems beinhalten neue Algorithmen und Forschungseingaben, so dass die Herausforderungen (und damit der Testmechanismus) nicht immer richtig vorausgesehen werden, wie z. B. das Testen von Funktionen in genau definierter Software.

Vor kurzem habe ich versucht, ein besseres Gesamtbild zu erhalten, um festzustellen, ob wir eine Prozessverbesserung benötigen. Als ich mich mit meinem Team zusammensetzte, sträubten sich viele: "Wir machen keine Unit-Tests mehr!" während andere dachten, wir sollten jetzt nicht anfangen, weil es niemals effektiv sein wird.

Sind Unit-Tests in einem relativ ausgereiften System nützlich? Sollten wir zumindest den Testumfang abhängig von der Laufzeit der Einheiten abwägen müssen? Verlangsamen Unit-Tests das Entwicklungstempo? Müssen Unit-Tests anders bewertet werden?

Was sind die Best Practices für das Testen einer ausgereiften Plattform in einer Umgebung mit häufigem Release-Early-Release?

Unit-Tests dienen nicht in erster Linie dazu, Fehler zu finden, sondern stellen sicher, dass die nächste Version Ihres Systems genauso stabil ist wie die vorherige Version. Je kürzer Ihr Release-Zyklus ist, desto wichtiger wird es, dass Sie diese Tests automatisch ausführen können, anstatt sie manuell durchzuführen.

Wenn Sie ein System mit einigen unabhängigen Teilen haben und zwischen zwei Releases nur in einem kleinen Teil des Systems gearbeitet haben, können Sie wahrscheinlich einige Komponententests für andere Teile des Systems weglassen. Sie sollten jedoch auf jeden Fall die Komponententests für die Teile verwenden (und erweitern), an denen Sie arbeiten.

Eine andere Sache ist, dass wenn ein System wächst, immer mehr zusätzliche Integrationstests erforderlich sind - dies bedeutet jedoch nicht, dass Sie weniger Komponententests benötigen.

Die eigentliche Frage hinter Ihrer könnte vielleicht eine andere sein. Ist es schwieriger geworden, Unit-Tests zu schreiben, seit Ihr System immer größer geworden ist? Sind Ihre "Unit" -Tests wirklich Unit-Tests oder testen sie die Dinge nicht mehr isoliert? Dies kann daran liegen, dass sie sich auf untergeordnete Teile des Systems stützen, die sich im Laufe der Zeit stabilisiert haben.

Diese Dinge passieren, weil Entwickler dazu neigen, vorhandene Bibliotheken und Code durch direkte Referenzierung wiederzuverwenden. Dies hat häufig den Effekt, dass das Schreiben von Komponententests schwieriger wird, da sie häufig eine komplexere Umgebung und mehr Testdaten bereitstellen müssen. Wenn dies Ihr Problem ist, sollten Sie sich mit den Schlüsselkonzepten Dependency Injection und Interface Segregation Principle vertraut machen , die Ihnen dabei helfen können, den Code einheitlicher zu testen.

Sie sollten sich mit der testgetriebenen Entwicklung befassen, bei der die Tests zuerst entworfen werden, und beschreiben, wie der neue Code beim Schreiben funktioniert. Sie bestehen dann die Tests.

Nach meiner Erfahrung führt dies dazu, dass Code schlanker und besser durchdacht wird, insbesondere für Bibliotheken, und es ist ein ausführbarer Teil der Spezifikation (was bedeutet, dass es sich immer um eine korrekte Dokumentation handelt).

Vorhandene Tests werden jedoch verwendet, um sicherzustellen, dass der Code weiterhin wie erwartet funktioniert. Es kann Codebrüche auffangen und Sie können sicherstellen, dass der Code von Drittanbietern beim Upgrade weiterhin wie erwartet funktioniert.

Wie von Doc Brown und Thorbjørn Ravn Andersen vorgeschlagen , kann eine Umgebung mit früher Release-Version häufig noch mehr von guten Unit-Tests und testgetriebener Entwicklung profitieren als eine Umgebung mit langen Release-Zyklen.

Wenn Sie über ein gutes kontinuierliches Integrationssystem und Tests verfügen, die die Funktionalität gut darstellen, haben Sie zu jedem Zeitpunkt eine gute Vorstellung davon, was funktioniert (da die Tests für diese Funktionalität bestanden werden) und was noch nicht implementiert wurde ( weil es keine Tests für diese Funktionalität gibt).