Definitionen

Ich denke, es ist wichtig, dass Sie Ihre Begriffe vor dieser Diskussion definieren.

Komponententest testet isoliert eine einzelne Einheit. Für mich ist das eine Klasse. Ein Komponententest erstellt ein Objekt, ruft eine Methode auf und überprüft ein Ergebnis. Es beantwortet die Frage "Tut mein Code, was ich vorhatte?"

Integrationstest testet die Kombination von zwei Komponenten im System. Es konzentriert sich auf die Beziehung zwischen den Komponenten, nicht die Komponenten selbst. Es beantwortet die Frage "Funktionieren diese Komponenten wie vorgesehen".

Systemtest testet das gesamte Softwaresystem. Es beantwortet die Frage "Funktioniert diese Software wie vorgesehen?"

Abnahmetest ist eine automatische Möglichkeit für den Kunden, die Frage zu beantworten: "Ist diese Software das, was ich denke, ich will?". Es ist eine Art Systemtest.

Beachten Sie, dass keiner dieser Tests auf Fragen wie "Ist diese Software nützlich?" oder "ist diese Software einfach zu benutzen?".

Alle automatisierten Tests sind begrenzt durch Axiom " Ende-zu-Ende ist weiter als Sie denken " - schließlich muss sich ein Mensch vor einen Computer setzen und auf Ihre Benutzeroberfläche schauen.

Vergleiche

Komponententests sind schneller und einfacher zu schreiben, schneller auszuführen und einfacher zu diagnostizieren. Sie sind nicht von "externen" Elementen wie einem Dateisystem oder einer Datenbank abhängig, daher sind sie viel einfacher / schneller / zuverlässiger. Die meisten Komponententests funktionieren weiterhin, wenn Sie umgestalten (und gute Komponententests sind die einzige Möglichkeit, sicher zu refaktorieren). Sie erfordern unbedingt, dass Ihr Code entkoppelt ist, was schwierig ist, es sei denn, Sie schreiben zuerst den Test. Diese Kombination von Faktoren bewirkt, dass die Red / Green / Refactor-Sequenz von TDD so gut funktioniert.

Systemtests sind schwer zu schreiben, da sie so viele Einstellungen durchlaufen müssen, um zu einer bestimmten Situation zu gelangen, die Sie testen möchten. Sie sind spröde, da jede Änderung des Verhaltens der Software die Reihenfolge beeinflussen kann, die zu der Situation führt, die Sie testen möchten, selbst wenn dieses Verhalten für den Test nicht relevant ist. Sie sind aus ähnlichen Gründen dramatisch langsamer als Komponententests. Fehler können sehr schwer zu diagnostizieren sein, sowohl weil es lange dauern kann, bis sie zum Fehlerpunkt kommen, als auch, weil so viel Software in den Fehler involviert ist. In einigen Software sind Systemtests sehr schwer zu automatisieren.

Integrationstests liegen dazwischen: Sie sind einfacher zu schreiben, auszuführen und zu diagnostizieren als Systemtests, aber mit einer größeren Abdeckung als Unit Tests.

Empfehlung

Verwenden Sie eine Kombination von Teststrategien, um die Kosten und Werte der einzelnen zu vergleichen.

Ja.

Selbst wenn alle "Einheiten" das tun, was sie tun sollen, ist es keine Garantie, dass das komplette System wie geplant funktioniert.

Ja, außerdem gibt es ein paar verschiedene Arten der Codeabdeckung

aus dem Wiki:

• Funktionsabdeckung - Wurde jede Funktion im Programm ausgeführt?
• Aussage Abdeckung - Wurde jede Zeile des Quellcodes ausgeführt?
• Entscheidungsabdeckung (auch Branch-Coverage genannt) - Hat jede Kontrollstruktur (z. B. eine if-Anweisung) sowohl true als auch false ausgewertet?
• Bedingungsabdeckung - Wird jeder boolesche Unterausdruck sowohl auf wahr als auch auf falsch ausgewertet (dies bedeutet nicht notwendigerweise eine Entscheidungsabdeckung)?
• Modifizierter Zustand / Entscheidungsabdeckung (MC / DC) - Hat jede Bedingung in einer Entscheidung über alle möglichen Ergebnisse mindestens einmal getroffen? Hat sich gezeigt, dass jede Bedingung das Entscheidungsergebnis unabhängig beeinflusst?
• Pfadabdeckung - Wurde jede mögliche Route durch einen bestimmten Teil des Codes ausgeführt?
• Ein- / Ausstiegsabdeckung - Wurde jeder mögliche Aufruf und Rückgabe der Funktion ausgeführt?

Die Pfadabdeckung zum Beispiel, nur weil jede Methode aufgerufen wurde, bedeutet nicht, dass Fehler nicht auftreten, wenn Sie verschiedene Methoden in einer bestimmten Reihenfolge aufrufen.

Erstens reicht die 100% -Testabdeckung nicht aus, selbst auf der Ebene der Gerätetests: Sie decken nur 100% der Anweisungen Ihres Codes ab. Was ist mit Pfaden in deinem Code? Was ist mit Eingabe- oder Ausgabedomänen?

Zweitens wissen Sie nicht, ob die Ausgabe von einer Sendereinheit mit der Eingabe von ihrer Empfängereinheit kompatibel ist. Dies ist der Zweck des Integrationstests.

Schließlich kann der Komponententest in einer anderen Umgebung als der Produktion durchgeführt werden. Integrationstests können Diskrepanzen aufdecken.

Sie können das Vorhandensein eines Fehlers nur mithilfe von Tests / Coverage nachweisen, aber Sie können nie beweisen, dass der Code mit Tests / Coverage fehlerfrei ist. Diese Tatsache gibt die Grenzen des Tests / der Abdeckung an. Das ist das gleiche in der Mathematik, Sie können einen Satz widerlegen, indem Sie ein Gegenbeispiel finden, aber Sie können niemals einen Satz beweisen, indem Sie kein Gegenbeispiel finden. Testing und Coverage sind also nur ein Ersatz für Korrektheitsbeweise, die so schwierig sind, dass sie fast nie verwendet werden. Tests und Coverage können die Qualität des Codes verbessern, es gibt jedoch keine Garantie. Es bleibt ein Handwerk und keine Wissenschaft.

Ich habe nicht wirklich eine Antwort gefunden, die diese Überlegungen behandelt. Jetzt spreche ich aus einer ganzheitlichen Systemperspektive, keine SW-Entwicklungsperspektive, aber ... Bei der Integration handelt es sich im Grunde um den Prozess, Produkte auf niedrigerer Ebene zu einem Produkt auf höherer Ebene zu kombinieren. Jede Ebene hat ihre eigenen Anforderungen. Obwohl es möglich ist, dass einige Anforderungen gleich sind, werden die allgemeinen Anforderungen für verschiedene Ebenen unterschiedlich sein. Dies bedeutet, dass die Testziele auf verschiedenen Ebenen unterschiedlich sind. Außerdem unterscheidet sich die Umgebungsumgebung des Produkts auf höherer Ebene von der des Produkts auf niedrigerer Ebene (z. B. können SW-Modultests in einer Desktop-Umgebung auftreten, während ein vollständig ladbares SW-Element getestet werden kann, wenn es in seine HW-Komponente geladen wird) ). Darüber hinaus haben Komponentenentwickler auf niedrigerer Ebene möglicherweise nicht das gleiche Verständnis für die Anforderungen und das Design wie die Produktentwickler auf höherer Ebene, sodass Integrationstests auch die Produktentwicklung auf niedrigerer Ebene bis zu einem gewissen Grad validieren.

Komponententests unterscheiden sich von Integrationstests.

Um nur einen Punkt zu nennen: Wenn ich wählen müsste, würde ich Komponententests ablegen und Integrationstests durchführen. Die Erfahrung lehrt, dass Komponententests helfen, Funktionalität sicherzustellen und auch Fehler im frühen Entwicklungszyklus zu finden.

Integrationstests werden durchgeführt, indem das Produkt so aussieht, wie es für die Endnutzer aussehen würde. Das ist auch wichtig.

Bei Komponententests geht es in der Regel darum, Ihre Klasse isoliert zu testen. Sie sollten so konzipiert sein, dass bestimmte Klasseneingaben vorhersagbare und erwartete Verhaltensweisen aufweisen.

Bei Integrationstests geht es in der Regel darum, Ihre Klassen miteinander und mit "externen" Programmen zu testen, die diese Klassen verwenden. Sie sollten sich darauf konzentrieren sicherzustellen, dass, wenn das gesamte Produkt Ihre Klassen nutzt, dies in der richtigen Weise geschieht.

"undurchsichtig (wenn jemand zerbrochen ist, muss er durch alle Schichten tauchen, um herauszufinden, was falsch ist)" - genau deshalb werden Integrationstests durchgeführt - andernfalls würden diese undurchsichtigen Probleme in der Produktionsumgebung auftauchen.

Ja, denn die Funktionalität Ihrer Software hängt davon ab, wie die verschiedenen Teile interagieren. Unit-Tests hängen davon ab, dass Sie mit den Eingaben kommen und die erwartete Ausgabe definieren. Dies garantiert nicht, dass es mit dem Rest Ihres Systems funktioniert.

Bei der Einführung von Codeänderungen, bei denen die Ausgabe bewusst geändert wird, ist das Testen der Ja-Integration ein Problem. Mit unserer Software minimieren wir dadurch, dass wir das sichere Ergebnis eines Integrationstests mit einem gespeicherten korrekten Ergebnis vergleichen.

Wir haben ein Werkzeug, das wir verwenden können, wenn wir sicher sind, dass wir die richtigen Ergebnisse erzielen. Es geht und lädt die alten gespeicherten korrekten Ergebnisse und modifiziert sie, um mit dem neuen Setup zu arbeiten.

Ich sehe routinemäßig alle Arten von Problemen, die durch gute Integrationstests aufgedeckt werden - vor allem, wenn Sie einen Teil Ihrer Integrationstests automatisieren können.

Komponententests sind großartig, aber Sie können eine 100% ige Codeabdeckung ohne 100% ige Relevanz in Ihren Komponententests erreichen. Du versuchst wirklich, verschiedene Dinge zu testen, oder? In Komponententests suchen Sie normalerweise nach Kantenfällen für eine bestimmte Funktion, während Integrationstests Ihnen Probleme auf einer höheren Ebene zeigen werden, wenn alle diese Funktionen zusammenwirken.

Wenn Sie eine API in Ihre Software einbauen, können Sie diese für automatisierte Integrationstests verwenden - ich habe in der Vergangenheit viel davon gelernt. Ich weiß nicht, dass ich so weit gehen würde zu sagen, dass ich Komponententests zugunsten von Integrationstests ablehnen würde, aber wenn sie richtig gemacht werden, sind sie eine wirklich mächtige Ergänzung.

Es sieht nicht so aus, als wäre es hier erwähnt, aber Sie können niemals 100% Einheitentestabdeckung haben (wenn Sie eine Datenbank haben). In dem Moment, in dem Sie einen Komponententest für Datenbankkonnektivität und CRUD-Operationen schreiben, haben Sie gerade einen Integrationstest erstellt. Der Grund liegt darin, dass Ihr Test jetzt eine Abhängigkeit außerhalb der einzelnen Arbeitseinheiten aufweist. Die Projekte, an denen ich gearbeitet habe, und die Entwickler, mit denen ich gesprochen habe, haben immer darauf hingewiesen, dass die verbleibenden 10% die DAO- oder Service-Schicht sind. Der beste Weg, dies zu testen, sind Integrationstests und eine Scheindatenbank (In-Memory-Datenbank). Ich habe Versuche gesehen, Verbindungen zu verspotten, um das DAO Unit-Test zu testen, aber ich verstehe den Punkt nicht wirklich - Ihr DAO ist nur eine Möglichkeit, Rohdaten von einem Format in ein anderes zu serialisieren, und Ihr Manager oder Delegierter wird entscheiden wie man es manipuliert.