Benötige ich einen Komponententest, wenn ich bereits einen Integrationstest habe?

Wenn ich bereits einen Integrationstest für mein Programm habe und alle bestanden haben, habe ich das gute Gefühl, dass es funktionieren wird. Was sind dann die Gründe, Unit-Tests zu schreiben / hinzuzufügen? Da ich ohnehin schon Integrationstests schreiben muss, schreibe ich nur Unit-Tests für Teile, die nicht durch Integrationstests abgedeckt sind.

Was ich weiß, sind die Vorteile des Unit-Tests gegenüber dem Integrationstest

• Klein und daher schnell zu laufen (aber das Hinzufügen eines neuen Geräts zum Testen von etwas wird bereits durch den Integrationstest getestet, was bedeutet, dass mein gesamter Testanzug größer und länger läuft)
• Das Auffinden von Fehlern ist einfacher, da nur eine Sache getestet wird (aber ich kann mit dem Schreiben eines Komponententests beginnen, um jedes einzelne Teil zu überprüfen, wenn mein Integrationstest fehlgeschlagen ist).
• Finden Sie Fehler, die möglicherweise nicht im Integrationstest gefunden wurden. zB Fehler maskieren / ausgleichen. (Aber wenn meine Integrationstests alle bestanden haben, was bedeutet, dass mein Programm funktioniert, gibt es sogar einen versteckten Fehler. Diese Fehler zu finden / zu beheben hat keine hohe Priorität, es sei denn, sie brechen zukünftige Integrationstests oder verursachen Leistungsprobleme.)

Und wir wollen immer weniger Code schreiben, aber beim Schreiben von Unit-Tests wird viel mehr Code benötigt (hauptsächlich Setup-Mock-Objekte). Der Unterschied zwischen einigen meiner Komponententests und Integrationstests besteht darin, dass ich bei Komponententests Scheinobjekte und bei Integrationstests echte Objekte verwende. Welche haben viele Duplikate und ich mag keinen duplizierten Code, auch in Tests, weil dies Overhead hinzufügen, um das Verhalten des Codes zu ändern (Refactor-Tool kann nicht alle Arbeit die ganze Zeit).

Sie haben gute Argumente für und gegen Unit-Tests vorgebracht. So dass Sie sich fragen, „ Muss ich Wert in den positiven Argumente sehen, die die Kosten in die negativen überwiegen? “ Ich sicher tun:

• Klein und schnell ist ein netter Aspekt beim Testen von Einheiten, wenn auch keineswegs der wichtigste.
• Das Lokalisieren von Fehlern ist extrem wertvoll. Viele Studien zur professionellen Softwareentwicklung haben gezeigt, dass die Kosten eines Fehlers mit zunehmendem Alter stark ansteigen und sich in der Software-Bereitstellungs-Pipeline niederschlagen.
• Das Auffinden von maskierten Fehlern ist wertvoll. Wenn Sie wissen, dass für eine bestimmte Komponente alle Verhaltensweisen überprüft wurden, können Sie sie auf eine Weise verwenden, die zuvor nicht verwendet wurde. Wenn die einzige Überprüfung über Integrationstests erfolgt, wissen Sie nur, dass sich die aktuellen Verwendungen korrekt verhalten.
• In der Praxis ist das Verspotten kostspielig, und das Aufrechterhalten von Verspottungen ist doppelt so hoch. Wenn Sie "interessante" Objekte oder Schnittstellen verspotten, müssen Sie möglicherweise sogar Tests durchführen, um sicherzustellen, dass Ihre verspiegelten Objekte Ihre realen Objekte korrekt modellieren!

In meinem Buch überwiegen die Vor- und Nachteile.

Ich halte es nicht für wichtig, einen vorhandenen Integrationstestfall als unwichtig neu zu implementieren.

Integrationstests sind für ältere Nicht-Tdd-Anwendungen oft viel einfacher zu schreiben, da die zu testenden Funktionen normalerweise eng miteinander verbunden sind, so dass das isolierte Testen von Einheiten (= nicht testen) schwierig / teuer / unmöglich sein kann.

> Then what are the reasons to write/add unit tests?

Meiner Meinung nach ist eine testgetriebene Entwicklung am effektivsten, wenn Sie die Komponententests vor dem eigentlichen Code schreiben . Auf diese Weise wird der Code, der die Tests erfüllt, mit einem Minimum an externen Referenzen, die leicht zu testen sind, klar getrennt.

Wenn der Code bereits ohne die Komponententests vorhanden ist, ist das anschließende Schreiben der Komponententests in der Regel sehr aufwändig, da der Code nicht für einfache Tests geschrieben wurde.

Wenn Sie TDD ausführen, ist der Code automatisch einfach zu testen.

Integrationstests sollten nur sicherstellen, dass mehrere Komponenten wie erwartet zusammenarbeiten. Ob die Logik der einzelnen Komponenten korrekt ist oder nicht, sollte durch Unit-Tests überprüft werden.
Die meisten Methoden haben mehrere mögliche Ausführungspfade. Denken Sie an Wenn-Dann-Sonst-Werte, Eingabevariablen mit unerwarteten oder einfach falschen Werten usw. Normalerweise denken Entwickler nur an den glücklichen Pfad: den normalen Pfad, der nicht schief geht. In Bezug auf diese anderen Pfade haben Sie zwei Möglichkeiten: Sie können Ihren Endbenutzer diese Pfade anhand der Aktionen untersuchen lassen, die er in der Benutzeroberfläche ausführt, und hoffen, dass sie Ihre Anwendung nicht zum Absturz bringen, oder Sie können Komponententests schreiben, die dies bestätigen das Verhalten dieser anderen Pfade und ergreifen Maßnahmen, wo erforderlich.

Einige der Gründe, auf die Sie in Ihrer Frage hingewiesen haben, sind wirklich wichtig und könnten für sich genommen durchaus für Unit-Tests sprechen, aber für YMMV. Wie oft führen Sie beispielsweise Ihre integrierte Testsuite aus? Ich habe die Erfahrung gemacht, dass integrierte Tests früher oder später so langsam werden, dass Sie sie nicht jedes Mal ausführen, wenn Sie eine Änderung vornehmen, und die Zeit zwischen dem Einfügen und Erkennen eines Fehlers sich verlängert.

Ein großer Fehler, den Sie möglicherweise machen, besteht darin, dem zu vertrauen

Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.

ist nicht wichtig. Erwarten Sie, dass Ihre Benutzer die Fehler für Sie finden? Ich bin der Meinung, dass es gefährlich ist, wenn man sich auf Abdeckungen aus integrierten Tests verlässt. Man kann sehr leicht einen hohen Abdeckungsgrad erzielen, aber in Wirklichkeit testet man nur sehr wenig.

Ich denke der kanonische Verweis gegen integrierte Tests sind die Beiträge von JBrains:

http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1

falls du sie noch nicht gelesen hast

Schließlich ist IMO das Feedback, das Sie von den Komponententests für Ihr Design erhalten können, von unschätzbarem Wert. Ein Design nach Bauchgefühl zu beurteilen und sich auf integrierte Tests zu verlassen, kann ebenfalls ein Fehler sein.

Wenn Sie davon ausgehen, dass Sie Ihren Code jemals modifizieren oder umgestalten müssen, sind Unit-Tests unerlässlich. Unit-Tests zeigen nicht nur Fehler zum Zeitpunkt des Codeschreibens, sondern auch, wann neue Fehler auftreten, wenn mehr Code geschrieben wird.

Ja, es ist viel besser, zuerst Ihre Integrations- und Unit-Tests zu schreiben, aber es ist sehr wertvoll, sie zu haben, auch wenn sie später geschrieben werden.