Einleitung
Kürzlich hatte ich eine sehr interessante Diskussion mit einem Kollegen darüber, warum man Software überhaupt testen sollte. Macht es uns nicht langsamer? Ist es nicht wichtiger, schnell Feedback von Benutzern zu bekommen, indem man die Software entwirft und dann nachträglich Tests hinzufügt?
Zuerst dachte ich: Was zum Teufel? Keine Tests?
Aber dann hatte mein Kollege tatsächlich einen Punkt. Das Schreiben von Tests macht die Softwareentwicklung deutlich langsamer als sie theoretisch sein könnte. Tests zu schreiben braucht Zeit. Auch ein gutes Test-Setup zu erstellen braucht Zeit. Und - ja - vielleicht ist es viel wichtiger, schnell Feedback von Benutzern zu bekommen, als Tests um ihrer selbst willen zu schreiben.
Also - bedeutet das ab jetzt keine Tests mehr?
Vielleicht nicht.
Wie üblich in der Softwareentwicklung haben wir es mit Wahrscheinlichkeiten von Erfolg und Misserfolg zu tun. Hier ist meine Meinung zu Tests:
Respektieren Sie die Testpyramide
Wenn Sie Tests schreiben, stellen Sie sicher, dass Sie Unit Tests schreiben. Verwenden Sie nur die echte zu testende Klasse und mocken Sie alles andere. Es gibt aus gutem Grund eine Testpyramide.
Sie können Projekte ohne End-to-End-Tests durchführen. Aber ich habe noch nie ein Projekt ohne eine Reihe aussagekräftiger Unit Tests erfolgreich gesehen.
Testen verbessert tatsächlich Ihren eigenen Code
Indem Sie einen Test schreiben und die zu testende Klasse überhaupt erst “testbar” machen, verbessern Sie Ihren Code. Die Tests werden zu Ihnen sprechen.
Wenn etwas schwer zu testen ist, bedeutet das, dass es vielleicht kein sehr guter Code ist. Refaktorieren Sie, bis die Sachen testbar, also modular sind, und machen Sie weiter.
Tests geben Ihnen Sicherheit beim Refactoring
Von Zeit zu Zeit braucht Software etwas Refactoring. Vielleicht muss ein neues Feature eingeführt werden, bei dem Sie wesentliche Teile des Codes umschreiben müssen. Oder eine externe Bibliothek muss durch etwas anderes ersetzt werden.
Tests geben Ihnen die Zuversicht, dass Sie den Code anfassen können und dass Änderungen keine Teile der Anwendung zerstören, an die Sie nicht einmal denken.
Es ist sehr, sehr wichtig, dass ein Team seinen eigenen Code nicht fürchtet. Das ist besonders wichtig für nicht statisch typisierte Sprachen (z.B. Javascript).
Wenn Sie im Team arbeiten, brauchen Sie Tests
Wenn Sie allein sind, brauchen Sie vielleicht keine Tests. Aber wenn es mindestens zwei Entwickler gibt, werden Sie von Zeit zu Zeit auf Merge-Konflikte stoßen. Einige Teams fürchten Merge-Konflikte wie die Pest und behandeln sie als Versagen. Das könnte nicht weiter von der Wahrheit entfernt sein.
Merge-Konflikte sind Teil der Softwareentwicklung und werden immer Teil Ihrer Arbeit als Ingenieur sein, wenn Sie in einem Team und an einem Projekt von angemessener Größe arbeiten.
Behandeln Sie Merge-Konflikte als etwas Positives. Und wissen Sie was? Tests helfen wieder dabei, diese Konflikte zu lösen - und sie helfen enorm dabei, sicherzustellen, dass Software nach einem Merge funktioniert.
Tests sind KEIN Selbstzweck - und Code Coverage ist problematisch
Tests nur um des Testens willen zu schreiben, ergibt KEINEN Sinn. Es ergibt KEINEN Sinn, nur die Code Coverage Ihrer Tests zu messen und daraus zu schließen, welche Arbeit Ihre Ingenieure leisten.
Code Coverage misst NICHT, ob Ihre Tests etwas Sinnvolles testen. Wenn Sie möchten, dass ich die Code Coverage erhöhe, kann ich das - ich kann die Code Coverage sogar auf 100% erhöhen - indem ich bedeutungslose Tests schreibe.
Aber das ist nicht das, was Sie wollen. Sie wollen ein funktionierendes Projekt.
Und deshalb können Sie natürlich die Menge der zu schreibenden Tests abwägen, oder welche Tests Sie schreiben, gegen einen frühen Start des Projekts und z.B. frühes Feedback von echten Benutzern. Es ergibt natürlich keinen Sinn, eine sehr schön getestete Software zu produzieren, die niemand nutzt.
Aber ich würde trotzdem sagen: Gute modulare Unit Tests sind unverzichtbar für eine Software von angemessener Größe, die von einem Team von mindestens zwei Personen geschrieben wird. Sie können bei der Menge der Unit Tests Kompromisse eingehen. Sie können durchaus alle Nicht-Unit-Tests weglassen (Medium Tests und Large Tests in Google-Sprache).
Stack Overflow zum Beispiel rühmte sich, nicht viele Tests zu schreiben - “wegen ihrer aktiven Community und der starken Nutzung von statischem Code”. Ja - das können Sie natürlich tun, wenn Sie das Testen an Ihre Community und Kunden auslagern.
Die goldene Regel der Tests: Wenn es einen Bug gibt, beheben Sie ihn und schreiben Sie einen Test
Das ist etwas, das immer sinnvoll ist: Sie können anfangs nur wenige Tests schreiben. Aber wenn Sie einen Bug entdecken - machen Sie es zur Praxis, einen Test dagegen zu schreiben - auf der niedrigstmöglichen Ebene. Und das bedeutet NICHT, standardmäßig einen End-to-End-Test zu schreiben.
Update 2022-11-29 - Stack Overflow ist jetzt stolz auf seine Tests
Wie oben erwähnt - Stack Overflow war sehr stolz darauf, keine (oder kaum) Tests zu schreiben. Aber das hat sich geändert. In einem ihrer neuesten Blogbeiträge beschrieben sie ihren neuen Ansatz.
Sie sagten auch klar, dass sie einfach keine zahlenden Kunden mehr nutzen können, um Bugs zu finden. Unit Tests sind ein Muss - sogar im Frontend-Code.
Mehr
- Bild oben von Chris Liverani auf https://unsplash.com/photos/ViEBSoZH6M4
