5 Gründe, warum Sie Ihren Code testen sollten

Es ist wie im Mathematikunterricht, als ich einen Beweis für das Theorem von Thales antreten musste und schrieb : "Sehen Sie nicht, dass B einen rechten Winkel hat?! Q.E.D.", aber er gab mir trotzdem eine Sechs. Sie wollen, dass etwas funktioniert, richtig? Also beginnen Sie zu programmieren, bis Ihre Funktion implementiert ist. Wenn sie implementiert ist, funktioniert sie, also brauchen Sie keine Tests. Sie wollen weitermachen und weitere coole Funktionen entwickeln. Plötzlich geht Funktion 1 kaputt, weil Sie etwas Seltsames in einem Dienst gemacht haben, der überall in Ihrer Anwendung wiederverwendet wird. Ok, wir beheben das Problem und aktualisieren die Seite so lange, bis alles wieder stabil ist. Das ist der Zeitpunkt, an dem Sie bereuen, dass Sie (oder noch besser Ihr Teamkollege) keine Tests geschrieben haben. In diesem Artikel nenne ich Ihnen 5 Gründe, warum Sie Tests schreiben sollten.

1. Regressionstest

Das in der Einleitung beschriebene Szenario ist ein typisches Beispiel für einen Regressionsfehler. Etwas funktioniert, geht aber kaputt, wenn Sie wegschauen.Wenn Sie eine 100%ige Codeabdeckung hätten, würde ein roter Fehler in der Konsole erscheinen oder - noch besser - eine Sirene würde in dem Raum ertönen, in dem Sie arbeiten.Auch wenn es einige Missverständnisse über die Abdeckung gibt, so zeigt sie doch zumindest anderen, dass es eine voll funktionsfähige Testsuite gibt. Und es kann Ihnen eine gute Note einbringen, wenn ein Audit-Unternehmen wie SIG Ihre Software inspiziert.

[caption id="attachment_16527" align="alignnone" width="473"] 100%ige Deckung fühlt sich so gut an[/caption]

100% Codeabdeckung bedeutet nicht, dass Sie alles getestet haben. Das bedeutet, dass die Testsuite so implementiert ist, dass sie jede Zeile des getesteten Codes aufruft, aber nichts über die Behauptungen aussagt, die während ihres Testlaufs gemacht wurden. Wenn Sie messen möchten, ob Ihre Spezifikationen eine angemessene Menge an Behauptungen enthalten, müssen Sie Mutationstests durchführen. Das funktioniert folgendermaßen. Eine automatische Aufgabe führt die Testsuite einmal aus. Dann werden einige Teile Ihres Codes geändert, vor allem Bedingungen umgedreht, for-Schleifen verkürzt/verlängert usw. Die Testsuite wird ein zweites Mal ausgeführt. Wenn die Tests nach den Änderungen fehlschlagen, wird für diesen Fall eine Behauptung aufgestellt, was gut ist.Allerdings fühlt sich eine 100%ige Abdeckung wirklich gut an, wenn Sie ein OCD-Mensch sind.Je besser Ihre Testabdeckung und Behauptungsdichte ist, desto höher ist die Wahrscheinlichkeit, dass Sie Regressionsfehler finden. Vor allem, wenn eine Anwendung wächst, können Sie während der Entwicklung auf viele Regressionsfehler stoßen, und das ist gut so.Angenommen, ein Formular zeigt ein lustiges Osterei an, wenn das eingegebene Geburtsdatum der 06-06-2006 ist und die für dieses Verhalten verantwortliche Codezeile ist in einer komplexen Methode versteckt. Ein anderer Entwickler könnte Änderungen an dieser Zeile vornehmen. Nicht, weil er nicht lustig wäre, sondern weil er es einfach nicht weiß. Bei einem fehlgeschlagenen Test fällt ihm sofort auf, dass er Ihr Osterei entfernt, während Sie ohne einen Test erst 2 Jahre später von der Entfernung erfahren würden.Dennoch enthält jede Anwendung Fehler, die Ihnen nicht bewusst sind. Wenn ein Endbenutzer Sie auf eine fehlerhafte Seite hinweist, finden Sie vielleicht heraus, dass der Link, auf den er geklickt hat, mit einer fehlenden Information generiert wurde, z.B. users//edit statt users/24/edit.Wenn Sie einen Fehler finden, schreiben Sie zuerst einen (fehlgeschlagenen) Test, der den Fehler reproduziert, und beheben Sie dann den Fehler. Dies wird nie wieder vorkommen. Sie haben gewonnen.

2. Verbessern Sie die Umsetzung durch neue Erkenntnisse

"Vorzeitige Optimierung ist die Wurzel allen Übels" ist etwas, das man oft hört. Das bedeutet nicht, dass Sie Ihre Lösung pragmatisch und ohne Code-Wiederverwendung implementieren müssen. Bei guter Software geht es nicht nur darum, ein Problem effektiv zu lösen, sondern auch um Wartbarkeit, Haltbarkeit, Leistung und Architektur. Tests können Ihnen dabei helfen. Sie zwingen Sie dazu, langsamer zu werden und nachzudenken. Wenn Sie mit dem Schreiben Ihrer Tests beginnen und Schwierigkeiten damit haben, kann dies ein Hinweis darauf sein, dass Ihre Implementierung verbessert werden kann. Außerdem können Sie bei Ihren Tests über Input und Output, Eckfälle und Abhängigkeiten nachdenken. Glauben Sie also, dass Sie alle Aspekte der von Ihnen geschriebenen Supermethode verstehen, die alles bewältigen kann? Schreiben Sie Tests für diese Methode und ein besserer Code ist garantiert. Testgetriebene Entwicklung hilft Ihnen sogar, Ihren Code zu optimieren, bevor Sie ihn überhaupt schreiben, aber das ist eine andere Diskussion.

3. Es spart Zeit, wirklich

Die häufigste Ausrede dafür, keine Tests zu schreiben, ist, dass Sie keine Zeit dafür haben oder Ihr Kunde nicht dafür bezahlen will. Das Schreiben von Tests kann in der Tat etwas Zeit kosten, selbst wenn Sie Boilerplate-Code-Eliminierungs-Frameworks wie Mox verwenden. Wenn ich Sie jedoch frage, ob Sie andere Design-Entscheidungen treffen würden, wenn Sie die Chance (und Zeit) hätten, neu anzufangen, würden Sie wahrscheinlich ja sagen. Ein komplettes Refactoring der Codebasis ist ein No-Go, denn Sie können nicht überblicken, welche Teile Ihrer Anwendung ausfallen werden. Wenn Sie die Herausforderung des Refactorings dennoch annehmen, wird es Ihnen zumindest viel Kopfzerbrechen bereiten und Sie viel Zeit kosten, die Sie für das Schreiben der Tests hätten verwenden können. Aber Sie hatten keine Zeit für das Schreiben von Tests, richtig? Also bleibt Ihre beschissene Implementierung bestehen.

Es kann immer ein Fehler auftreten, selbst bei gut refaktorisiertem Code. Wie oft haben Sie sich nach einem Tag harter Arbeit gesagt, dass Sie 90% Ihrer Zeit damit verbringen, einen fiesen Fehler zu finden und zu beheben? Sie wollen doch coole Anwendungen schreiben, nicht Fehler beheben. Wenn Sie Ihren Code sehr gut getestet haben, werden 90 % der eingeführten Fehler von Ihren Tests abgefangen. Puh, das hat den Tag gerettet. Sie können sich darauf konzentrieren, coole Sachen zu schreiben. Und Tests. Am Anfang kann das Schreiben von Tests mehr als die Hälfte Ihrer Zeit in Anspruch nehmen, aber wenn Sie den Dreh raus haben, wird das Schreiben von Tests zur zweiten Natur. Es ist wichtig, dass Sie Code für eine langfristige Perspektive schreiben. Wenn eine Anwendung wächst, zahlt es sich wirklich aus, Tests zu haben. Sie sparen Zeit und die Entwicklung macht mehr Spaß, da Sie nicht durch schwer zu findende Fehler behindert werden.

4. Selbstaktualisierende Dokumentation

Das Schreiben von sauberem, selbstdokumentierendem Code ist eines der wichtigsten Dinge, an die wir uns halten. Nicht nur für Sie selbst, besonders wenn Sie den Code eine Weile nicht gesehen haben, sondern auch für Ihre Entwicklerkollegen. Wir schreiben nur dann Kommentare, wenn ein Teil des Codes besonders schwer zu verstehen ist. Welchen Stil Sie auch immer bevorzugen, es muss in irgendeiner Weise klar sein, was der Code tut. // Beware! Dragons beyond this point! Einige Leute lesen gerne die Kommentare, andere lesen die Implementierung selbst, aber wieder andere lesen die Tests. Was ich an den Tests mag, zum Beispiel wenn Sie ein Framework wie Jasmine verwenden, ist, dass sie einen strukturierten Überblick über alle Funktionen der Methode bieten. Wenn Sie eine separate Dokumentationsdatei haben, kann diese so strukturiert sein, wie Sie wollen, aber das Hauptproblem bei der Dokumentation ist, dass sie nie auf dem neuesten Stand ist. Entwickler schreiben nicht gerne Dokumentationen und vergessen, sie zu aktualisieren, wenn sich eine Methodensignatur ändert, so dass sie schließlich aufhören, Dokumentationen zu schreiben.Entwickler schreiben auch nicht gerne Tests, aber sie erfüllen zumindest mehr Zwecke als Dokumentationen. Wenn Sie die Testsuite als Dokumentation verwenden, ist Ihre Dokumentation immer auf dem neuesten Stand, ohne zusätzlichen Aufwand!

5. Es macht Spaß

Heutzutage gibt es keine Tester und Entwickler mehr. Die Entwickler sind die Tester. Leute, die gute Tests schreiben, sind auch die besten Programmierer. Eigentlich ist Ihr Test auch ein Programm. Wenn Sie also gerne programmieren, sollten Sie auch gerne Tests schreiben. Der Grund, warum sich das Schreiben von Tests unproduktiv anfühlen kann, ist, dass Sie das Gefühl haben, nichts Neues zu produzieren.

[caption id="attachment_16528" align="aligncenter" width="480"] Ist das Gebäude rot? Bringen Sie das sofort in Ordnung! [/caption]

Bei einem modernen Softwareentwicklungsansatz sollten Ihre Tests jedoch ein integrierter Bestandteil Ihrer Anwendung sein. Die Tests können mit Build-Tools wie Grunt und Gulp automatisch ausgeführt werden. Sie können zum Beispiel in einer kontinuierlichen Integrationspipeline über Jenkins laufen. Wenn Sie wirklich cool sind, wird automatisch ein neues Deployment in die Produktion durchgeführt, wenn die Tests bestanden werden und alles andere in Ordnung ist. Mit Tests haben Sie mehr Gewissheit, dass Ihr Code produktionsreif ist. Es können auch viele Messwerte generiert werden, wie z.B. Abdeckungs- und Mutationstests, die den OCD-orientierten Entwicklern ein breites Lächeln entlocken, wenn alles im grünen Bereich ist und die Punktzahl 100% beträgt. Wenn die Testsuite fehlschlägt, ist es oberste Priorität, dies zu beheben, um die Codebasis in gutem Zustand zu halten. Es erfordert etwas Disziplin, aber wenn Sie sich daran gewöhnt haben, macht es mehr Spaß, neue Funktionen zu entwickeln und coole Sachen zu machen.