Ich habe kürzlich etwa 70% der Zeit damit verbracht, einen Feature-Integrationstest zu schreiben. Irgendwann dachte ich "Verdammt, all die harte Arbeit, die es testet, ich weiß, dass ich hier keine Fehler habe, warum arbeite ich so hart daran? Lass uns einfach die Tests überfliegen und sie schon beenden ... "
Fünf Minuten später schlägt ein Test fehl. Detaillierte Inspektion zeigt, dass es ein wichtiger, unbekannter Fehler in einer 3rd-Party-Bibliothek ist, die wir verwenden.
Also ... wo ziehst du deine Linie darüber an, was du im Glauben testen sollst? Testen Sie alles oder den Code, von dem Sie die meisten Fehler erwarten?
Meiner Meinung nach ist es wichtig, beim Testen pragmatisch zu sein. Priorisieren Sie Ihre Testbemühungen auf die Dinge, die am wahrscheinlichsten ausfallen, und / oder auf die Dinge, die am wichtigsten sind, die nicht versagen (d. H. Wahrscheinlichkeit und Konsequenzen berücksichtigen).
Denken Sie nach, anstatt blind einer Metrik zu folgen, z. B. Codeabdeckung.
Stoppen Sie, wenn Sie mit der Testsuite und Ihrem Code vertraut sind. Gehen Sie zurück und fügen Sie weitere Tests hinzu, wenn (falls?) Dinge fehlschlagen.
Wenn Sie keine Angst mehr haben, mittlere bis große Änderungen an Ihrem Code vorzunehmen, haben Sie wahrscheinlich genug Tests.
Gute Frage!
Erstens - es klingt wie Ihre umfangreichen Integrationstests sich ausgezahlt haben:)
Aus meiner persönlichen Erfahrung:
Wie viel ist genug? Schwierige Frage - ich glaube nicht, dass es jemals genug geben kann!
"Zu viel von allem ist gerade genug."
Ich beachte keine strikten TDD-Praktiken. Ich versuche, genügend Komponententests zu schreiben, um alle Codepfade abzudecken und alle Randfälle auszuüben, die ich für wichtig halte. Im Grunde versuche ich zu antizipieren, was schief gehen könnte. Ich versuche auch, die Menge des Testcodes zu vergleichen, den ich schreibe, wie spröde oder wichtig der Code unter Test ist.
Ich bin streng in einem Bereich: Wenn ein Fehler gefunden wird, schreibe ich zuerst einen Test, der den Fehler ausübt und fehlschlägt, den Code ändert und verifiziere, dass der Test bestanden wird.
Gerald Weinbergs klassisches Buch " Die Psychologie der Computerprogrammierung hat viele von guten Geschichten über das Testen. Eine, die ich besonders mag, ist in Kapitel 4 " Programmierung als soziale Aktivität " " Bill "bittet einen Mitarbeiter, seinen Code zu überprüfen und sie finden siebzehn Fehler in nur dreizehn Aussagen. Code-Reviews bieten zusätzliche Augen, um Fehler zu finden. Je mehr Augen Sie verwenden, desto größer ist die Wahrscheinlichkeit, dass Sie immer kleinere Fehler entdecken. Wie Linus sagte: "Wenn man genug Augäpfel hat, sind alle Käfer flach." Ihre Tests sind im Grunde robotische Augen, die zu jeder Tages- und Nachtzeit Ihren Code so oft ansehen, wie Sie wollen und Sie wissen lassen, ob alles noch koscher ist / p>
Wie viele Tests ausreichen, hängt davon ab, ob Sie von Grund auf neu entwickeln oder ein bestehendes System pflegen.
Wenn Sie von Grund auf neu beginnen, möchten Sie nicht Ihre ganze Zeit damit verbringen, Tests zu schreiben und nicht zu liefern, weil die 10% der Funktionen, die Sie programmieren konnten, umfassend getestet wurden. Es wird eine gewisse Priorisierung geben. Ein Beispiel sind private Methoden. Da private Methoden von dem Code verwendet werden müssen, der in irgendeiner Form sichtbar ist (public / package / protected), können private Methoden als von den Tests für die besser sichtbaren Methoden abgedeckt betrachtet werden. Hier müssen Sie einige White-Box-Tests einschließen, wenn es im privaten Code einige wichtige oder obskure Verhaltensweisen oder Randfälle gibt.
Tests sollten Ihnen helfen, sicherzustellen, dass Sie 1) die Anforderungen verstehen, 2) sich an gute Designpraktiken halten, indem Sie die Testbarkeit codieren, und 3) wissen, wenn zuvor existierender Code nicht mehr funktioniert. Wenn Sie einen Test für ein Feature nicht beschreiben können, würde ich wetten, dass Sie das Feature nicht gut genug verstehen, um es sauber zu codieren. Die Verwendung von Komponententestcode zwingt Sie dazu, Dinge wie Argumente wie Datenbankverbindungen oder Instanzfabriken als Argumente zu übergeben, statt der Versuchung nachzugeben, dass die Klasse viel zu viel von sich selbst macht und sich in ein "Gott" -Objekt verwandelt. Wenn Sie Ihren Code zu Ihrem Kanarienvogel machen, können Sie mehr Code schreiben. Wenn ein zuvor bestandener Test fehlschlägt, bedeutet dies eines von zwei Dingen. Entweder erfüllt der Code nicht mehr das, was erwartet wurde, oder die Anforderungen für das Feature haben sich geändert und der Test muss lediglich aktualisiert werden, um den neuen Anforderungen zu entsprechen.
Wenn Sie mit vorhandenem Code arbeiten, sollten Sie in der Lage sein zu zeigen, dass alle bekannten Szenarien abgedeckt sind, so dass Sie bei der nächsten Änderungsanforderung oder Bugfixierung in das Modul, das Sie für richtig halten, graben können Sorge, "Was ist, wenn ich etwas kaputt mache", was dazu führt, dass ich mehr Zeit damit verbringe, auch kleine Korrekturen zu testen, dann musste ich den Code tatsächlich ändern.
Also können wir Ihnen keine harte und schnelle Anzahl von Tests geben, aber Sie sollten für eine Ebene der Berichterstattung schießen, die Ihr Vertrauen in Ihre Fähigkeit erhöht, Änderungen vorzunehmen oder Funktionen hinzuzufügen, sonst sind Sie wahrscheinlich am Punkt angelangt von verminderten Renditen.
Wenn Sie oder Ihr Team Messwerte überwacht haben, können Sie sehen, wie viele Fehler bei jedem Test während des Softwarelebenszyklus gefunden werden. Wenn Sie einen akzeptablen Schwellenwert definiert haben, bei dem die Testzeit die Anzahl der gefundenen Fehler nicht rechtfertigt, dann ist dies der Punkt, an dem Sie aufhören sollten.
Sie werden wahrscheinlich nie 100% Ihrer Fehler finden.
Ich verbringe viel Zeit mit Komponententests, aber sehr wenig mit Integrationstests. Komponententests erlauben es mir, ein Feature in einer Strukturweise aufzubauen. Und jetzt haben Sie einige schöne Dokumentation und Regressionstests, die bei jedem Build ausgeführt werden können
Integrationstests sind eine andere Sache. Sie sind schwer zu warten und integrieren per definitionem viele verschiedene Funktionen, oft mit einer Infrastruktur, mit der man nur schwer arbeiten kann.
Hinweis: Meine Antwort bezieht sich hauptsächlich auf Integrationstests. TDD ist sehr unterschiedlich. Es wurde bereits in SO behandelt, und Sie hören dann auf zu testen, wenn Sie keine Funktionalität mehr hinzufügen können. Bei TDD geht es um Design, nicht um Bug-Entdeckung.
Ich bevorzuge so viel wie möglich Unit-Test. Eine der größten Nebenwirkungen (abgesehen von der Verbesserung der Codequalität und der Vermeidung von Fehlern) besteht meines Erachtens darin, dass hohe Unit-Test-Anforderungen eine erfordern, um die Art und Weise zu ändern, wie sie Code schreiben zum besseren. So hat es zumindest für mich geklappt.
Meine Klassen sind kohärenter, einfacher zu lesen und viel flexibler, da sie so konzipiert sind, dass sie funktional und testbar sind.
Dies bedeutet, dass ich die Anforderungen für die Einheitentestabdeckung von 90% (Zeile und Zweig) mit junit und cobertura (für Java) festlege. Wenn ich der Meinung bin, dass diese Anforderungen aufgrund der Art einer bestimmten Klasse (oder Fehlern in cobertura) nicht erfüllt werden können, mache ich Ausnahmen.
Komponententests beginnen mit der Abdeckung und funktionieren wirklich für Sie, wenn Sie sie verwendet haben, um die Randbedingungen realistisch zu testen. Für Ratschläge, wie dieses Ziel zu implementieren ist, haben die anderen Antworten alle richtig.
Dieser Artikel gibt einige sehr interessante Einblicke in die Effektivität von Benutzertests mit unterschiedlichen Nutzerzahlen. Es schlägt vor, dass Sie ungefähr zwei Drittel Ihrer Fehler finden, wenn nur drei Benutzer die Anwendung testen, und 85% Ihrer Fehler mit nur fünf Benutzern.
Komponententests sind schwieriger zu bewerten. Ein Vorschlag, den Sie im Auge behalten sollten, ist, dass Komponententests helfen können, Ihre Überlegungen zur Entwicklung des zu testenden Codes zu organisieren. Sobald Sie die Anforderungen für einen Code geschrieben haben und ihn zuverlässig überprüfen können, können Sie ihn schneller und zuverlässiger schreiben.
Ich habe 1,5 Jahre in QA gearbeitet, bevor ich Entwickler wurde.
Man kann nie alles testen (mir wurde gesagt, wenn trainiert würde alle Permutationen eines einzelnen Textfelds länger dauern als das bekannte Universum).
Als Entwickler liegt es nicht in Ihrer Verantwortung, die Prioritäten zu kennen oder anzugeben, was zu testen und was nicht zu testen ist . Das Testen und die Qualität des Endprodukts liegen in der Verantwortung, aber nur der Kunde kann die Prioritäten der Features sinnvoll angeben, es sei denn, Ihnen wurde diese Verantwortung ausdrücklich übertragen. Wenn es kein QA-Team gibt und Sie nicht wissen, fragen Sie den Projektmanager, um herauszufinden und zu priorisieren.
Testen ist eine risikoreduzierende Übung und der Klient / Benutzer wird wissen, was wichtig ist und was nicht. Die Verwendung einer Test-First-Driven-Entwicklung von Extreme Programming wird hilfreich sein, so dass Sie eine gute Testbasis haben und nach einer Änderung einen Regressionstest durchführen können.
Es ist wichtig zu beachten, dass Code aufgrund der natürlichen Selektion "immun" gegenüber Tests werden kann. Code Complete sagt, wenn ein Fehler behoben wird, um einen Testfall dafür zu schreiben und nach ähnlichen Fehlern zu suchen, ist es auch eine gute Idee, einen Testfall für ähnliche Fehler zu schreiben.
Tags und Links unit-testing tdd integration-testing