Eine berechtigte Frage, oder?

Aber wie gehen wir am besten vor?

Wir haben auf der einen Seite massiv viele Zeilen Code, aber eben keinerlei Test. Das genau ist in vieler Hinsicht schon ein massiver Fehler. Woher wissen wir eigentlich, dass der Source nicht massive Sicherheitsprobleme hat?

Aus meiner Sicht ist es immer natürlich besser direkt mit dem Verständnis des Codes zu beginnen und eben mit der Codeanalyse auch gleichzeitig eine gewisse Spur von Expertise

• Codeanalysen: Beginnt mit der Codeanalyse und dem Verständnis: Startet damit, die Architektur und Funktionalität des Codebestands zu verstehen. Dies könnte das Durchlesen von Dokumentationen beinhalten, falls verfügbar, sowie das Untersuchen des Codes selbst. Identifiziert kritische Bereiche, Module oder Funktionen, die für die ordnungsgemäße Funktion der Anwendung unerlässlich sind.
• Identifiziert Hochrisikobereiche: Fokussiert euch auf kritische Funktionalitäten oder Module, die bei einem Ausfall wahrscheinlich den größten Einfluss haben. Sucht nach komplexen Algorithmen, Ein- und Ausgabevorgängen oder Bereichen, in denen Fehler am wahrscheinlichsten auftreten.
• Priorisiert: Priorisiert die identifizierten Hochrisikobereiche für das Testen. Erwägt, mit Bereichen zu beginnen, die für die Funktionalität der Anwendung am wichtigsten sind oder in denen Fehler am wahrscheinlichsten auftreten.
• Unittesting: Beginnt damit, Unittests für einzelne Funktionen oder Module zu schreiben. Unittests konzentrieren sich darauf, kleine Codeeinheiten isoliert zu testen. Wenn der Codebestand nicht für einfaches Unittesting strukturiert ist, erwägt eine Refaktorisierung, um ihn testbarer zu machen.
• Integrationstesting: Sobald ihr Unittests implementiert habt, geht zum Integrationstesting über. Integrationstests konzentrieren sich darauf, wie verschiedene Teile des Systems zusammenarbeiten. Testet Interaktionen zwischen Modulen, Komponenten oder externen Abhängigkeiten.
• Regressionstesting: Nach der Implementierung von Tests für kritische Bereiche solltet ihr Regressionstests hinzufügen, um sicherzustellen, dass neue Codeänderungen keine neuen Fehler einführen oder vorhandene Funktionalität beeinträchtigen. Automatisiert Regressionstests, wo immer möglich, um Probleme frühzeitig im Entwicklungsprozess zu erkennen.Kontinuierliches Testen und Integration: Implementiert eine Continuous Integration (CI)-Pipeline, um den Testprozess zu automatisieren. Dadurch werden Tests automatisch durchgeführt, wenn Änderungen am Codebestand vorgenommen werden. Integriert das Testen in den Entwicklungsworkflow, um euch dazu zu ermutigen, Tests für neuen Code zu schreiben und vorhandenen Code zu refaktorisieren, um ihn testbarer zu machen.
• Codeüberprüfung: Integriert Codeüberprüfungen in den Entwicklungsprozess, um sicherzustellen, dass neue Codeänderungen gründlich getestet werden und bewährten Praktiken entsprechen. Ermutigt euch dazu, testbaren Code zu schreiben, und gebt Anleitungen zum Schreiben effektiver Tests.
• Dokumentation und Wissensaustausch: Dokumentiert Teststrategien, bewährte Praktiken und spezifische Testfälle oder Szenarien. Teilt Wissen und Erfahrungen mit dem Testen im Team, um Testpraktiken zu verbessern und Konsistenz sicherzustellen.
• Iteration und Verbesserung: Testing ist ein fortlaufender Prozess. Überwacht und verbessert kontinuierlich die Testabdeckung und -effektivität im Laufe der Zeit. Lernt aus Fehlern und passt die Teststrategie entsprechend an.

 

Codeanalyse

Unittests

Stellt klar: Unit-Tests sind nicht länger eine optionale Aufgabe.

Zeitraum

Alle Code-Änderungen werden jetzt getestet, je nach Bedarf neu oder aktualisiert. Die ersten Tests werden WIRKLICH schwer sein, da es am Anfang so viele Hürden gibt und die Lernkurve steil ist. Plant also vielleicht einen oder sechs Monate ein, um alle mit Schulungen, Präsentationen, Coaching und Nachhilfe darauf vorzubereiten.

Um so streng zu sein (der gesamte Code muss jetzt getestet werden), müsst ihr zunächst mit mehreren Ebenen und Teilen der Organisation zusammenarbeiten, um die Leute vorzubereiten und mit den Ressourcen und dem Wissen auszustatten, das sie für eine so große Veränderung brauchen.

Es kann leicht mehrere Monate dauern, bis eine solche Veränderung in Gang kommt, und ein bis drei Jahre, bis sie in Schwung kommt, sodass die Unternehmensleitung für einen langen Zeitraum bereit sein und ihre Erwartungen festlegen muss. Das Ergebnis ist ein modernes Unternehmen, das sich im Wettbewerb behauptet und gewinnt. Die Alternative ist der Untergang des Unternehmens.

Phase 1 – Beginnen Sie mit der Einführung der Tests

Schritt 1) Schreiben Sie einen „Wahr ist wahr“-Test.
Schritt 2) Schreiben Sie einen Test „Aufruf einer einfachen Methode im Anwendungscode funktioniert“.
Schritt 3) Schreiben Sie einen Unit-Test für eine einfache Methode, die alle Abhängigkeiten abbildet und ausblendet.

Phase 2 – Anwendung der Tests auf die tatsächliche Entwicklung

Für alle Code-Änderungen in der Zukunft:

Schritt 1) Schreiben Sie Tests, die zusammen mit dem Code übertragen werden.
Schritt 2) Schreiben Sie fehlgeschlagene Tests, bevor Sie den Anwendungscode schreiben.
Schritt 3) Schreiben Sie Tests für den Rückstand der fehlenden Tests

Machen Sie bei all diesen Schritten neben den Vorteilen auch die Schwierigkeiten deutlich. Verwenden Sie einen CI-Server, auf dem Ihre Zweige und Tests laufen. Wie circleCI zum Beispiel. Legen Sie die Innereien offen, um sie zu verbessern.

„Tests zu haben hilft uns nicht wirklich, wenn wir keine Möglichkeit haben, sie auszuführen. „Das ist nur eine von Dutzenden Ausreden von Leuten, die nicht davon überzeugt sind, dass Testen eine wirklich tolle Sache ist – für Entwickler!

Außerdem, seien wir ehrlich, MUSS ein Entwickler seinen Code irgendwie ausführen, um sicherzustellen, dass der glückliche Pfad tatsächlich ohne Syntaxfehler funktioniert. Niemand, den ich je gesehen habe, schreibt Code „blind“. Das Testen findet bereits statt, es wurde nur noch nicht formalisiert und automatisiert, das ist wahrscheinlich der Fall.

Ich selbst habe früher Code ohne automatisierte Tests geschrieben (man kann wohlgemerkt sagen, dass ich ihn oft getestet habe), und zwar Millionen von Zeilen. Ihn zu ändern war schrecklich! Tests sind der beste Freund eines Entwicklers. Ich meine, wie kann man Code mit Zuversicht umgestalten – das Geheimnis der Qualität – wenn man keine Tests hat, die einen schützen? Der Anreiz, etwas zu verbessern, aber zu riskieren, etwas anderes kaputt zu machen, führt meiner Erfahrung nach dazu, dass überall Mist hinterlassen wird. Ist erst einmal ein Fenster zerbrochen, ist das Haus schnell zertrümmert (broken window theory).
Es gelingt oft nicht, Menschen mit Argumenten umzustimmen, daher ist es wichtig, mit gutem Beispiel voranzugehen und Mitarbeiter zu gewinnen.