Müssen Sie Unit- und Integrationstests durchführen, wenn Sie bereits funktionale Tests durchführen?

Question

Die Mitarbeiter meines Unternehmens betrachten Unit-Tests als eine Menge zusätzlicher Arbeit, die weniger Vorteile bietet als die bestehenden funktionalen Tests. Sind Unit- und Integrationstests es wert? Beachten Sie eine große bestehende Codebasis, die nicht mit Blick auf Tests entwickelt wurde.

Answer 1

Ja, sie sind es wert, ich bin jetzt schneller beim Programmieren, seit ich angefangen habe, meinen Code zu testen. Ich verbringe weniger Zeit damit, Fehler zu beheben und mehr Zeit damit, darüber nachzudenken, was mein Code tun sollte.

Answer 2

Eine Anwendung, bei der ich als Berater für die FAT(Test)ing hinzugezogen wurde, bestand aus einer 21.000 Zeilen langen Switch-Anweisung. Die meisten Funktionseinheiten bestanden aus ein paar Dutzend bis ein paar hundert Zeilen in einer Case-Anweisung. Die Anwendung wurde in mehreren Varianten erstellt, so dass es viele #ifdef-Abschnitte in der switch-Anweisung gab.

Sie wurde nicht für Unit-Tests konzipiert - sie wurde überhaupt nicht berücksichtigt.

(Es wurde in dem Sinne entworfen, dass es eine eindeutige, leicht zu verstehende Architektur gab - malloc eine Struktur, senden Sie die Hauptschleife eine Benutzer-Nachricht mit dem Zeiger auf die Struktur als die lparam und dann frei, wenn die Nachricht verarbeitet wird. Aber die Form folgte nicht der Funktion, was der zentrale Grundsatz eines guten Designs ist. )

Das Hinzufügen von Unit-Tests für neue Funktionen würde einen großen Bruch mit dem Muster bedeuten; entweder müssten Sie Ihren Code an einer anderen Stelle als dem großen Schalter unterbringen und die Komplexität des Variantenauswahlmechanismus verdoppeln, oder Sie müssten eine große Menge an Gerüsten erstellen, um die Nachrichten in die Warteschlange zu stellen, um die neue Funktion auszulösen.

Obwohl es also durchaus wünschenswert ist, neue Funktionen zu testen, ist dies nicht immer praktikabel, wenn ein System nicht bereits gut durchdacht ist. Entweder ist es mit erheblichem Aufwand verbunden, das System so umzugestalten, dass Unit-Tests möglich sind, oder man testet den Code und fügt ihn in das bestehende Framework ein - und eine Kopie von Unit-getestetem Code ist kein Unit-getesteter Code.

Answer 3

Man testet, wenn man etwas über etwas wissen will. Wenn Sie wissen, dass Ihr Produkt (System, Einheit, Dienstleistung, Komponente...) funktionieren wird, brauchen Sie es nicht zu testen. Wenn Sie unsicher sind, ob es funktionieren wird, haben Sie wahrscheinlich einige Fragen dazu. Ob es sich lohnt, diese Fragen zu beantworten, ist eine Frage des Risikos und der Prioritäten.

Wenn Sie sich sicher sind, dass Ihr Produkt funktionieren wird und Sie keine Fragen dazu haben, gibt es noch eine Frage, die sich lohnt: Warum habe ich keine Fragen?

---Michael B.

Answer 4

Unit-Tests bedeuten zwar zusätzliche Arbeit, aber auf lange Sicht zahlt sich das aus. Hier sind die Vorteile gegenüber Integrationstests:

• erhalten Sie eine Regressionssuite, die im Falle einer Überarbeitung als Sicherheitsnetz fungiert - dasselbe gilt für Integrationstests, obwohl es schwer zu sagen ist, ob der Test einen Teil des Codes abdeckt.
• Unit-Tests geben eine sofortige Rückmeldung, wenn der Code geändert wird - und das Rückmeldung kann sehr genau sein und auf die Methode verweisen, in der die Anomalie ist.
• Diese Tests sind kostengünstig: Sie laufen sehr schnell ab (in der Regel einige Sekunden), ohne jegliche Installation oder Bereitstellung, nur kompilieren und testen . So können sie oft durchgeführt werden.
• Es ist einfach, einen neuen Test hinzuzufügen, um ein Problem zu reproduzieren, sobald es erkannt wurde, und die Regressionssuite zu erweitern, oder eine Frage zu beantworten ("was passiert, wenn diese Funktion nicht mit einem Null-Parameter aufgerufen wird ...").

Natürlich gibt es einige Überschneidungen zwischen den beiden, aber sie ergänzen sich, da sie beide Vorteile bieten.

Wie jeder Softwareentwicklungsprozess muss auch das Testen entsprechend angepasst werden. den Projektanforderungen angepasst werden.

Bei einer großen Legacy-Codebasis, Legacy im Sinne von nicht unitgetestet, würde ich empfehlen, Unit-Tests auf neue Funktionen zu beschränken, die dem Code Unit-Tests schwer einzuführen sein können. Diesbezüglich, kann ich mich nur der Empfehlung aus dem Buch "Working Effectively with legacy code" Buch unterstützen, um Unit-Tests in eine bestehende Codebasis zu bringen.