Wie organisiert man Integrationstests?

Question

Wenn Unit-Tests zu schreiben, ich habe in der Regel eine Test-Klasse pro Produktion Klasse, so meine Hierarchie so ähnlich aussehen:

src/main 
    -package1 
    -classA 
    -classB 
    -package2 
    -classC 
src/test 
    -package1 
    -classATests 
    -classBTests 
    -package2 
    -classCTests 

jedoch, wenn die Integration tun prüft die Organisation wird weniger starr. Zum Beispiel kann ich eine Testklasse haben, die classA und classB in Verbindung prüft. Wo würdest du es hinstellen? Was ist mit einer Testklasse, die classA, classB und classC zusammen testet?

Auch Integrationstests erfordern normalerweise externe Eigenschaften oder Konfigurationsdateien. Wo platzierst du sie und nimmst du eine Namenskonvention für sie?

Answer 1

Vielleicht erstellen Sie ein Integrationstests-Verzeichnis unter src/test? Sicher, bei Integrationstests wird die Trennung weniger klar, aber es gibt etwas, das die Gruppen A, B und C zusammenfasst, nicht wahr? Ich würde damit beginnen und sehen, wie es läuft. Es ist schwierig, sofort eine perfekte Lösung zu finden, und eine "OK" -Lösung ist besser als keine Lösung.

Answer 2

Unsere Integrationstests neigen dazu, auf die gleiche Weise wie unsere Spezifikationen organisiert zu sein. Und sie neigen dazu, nach Kategorien und/oder Merkmal gesammelt zu werden.

Answer 3

Es scheint, dass Ihre Integrationstests Unit-Tests auf höherer Ebene sind, da Sie sie immer noch an eine oder mehrere Klassen binden. Versuchen Sie, eine Klasse auszuwählen, die von allen anderen (transitiv) von der Gruppe abhängt, und verbinden Sie den Test mit einer solchen Klasse.

Wenn Sie echte Integrationstests haben, ist die Verknüpfung mit konkreten Klassen von geringem Wert. Dann werden die Tests nach Anwendungsbereichen (Domänen) und nach Arten von Funktionalität klassifiziert. Zum Beispiel sind Domains Aufträge, Lieferungen, Rechnungen, Berechtigungen usw. und Funktionalitätstypen sind Transaktions-, Web-, Messaging-, Batch-, etc. Ihre Permutationen würden Ihnen einen schönen ersten Schritt geben, wie Sie Integrationstests organisieren.

Answer 4

Ich habe festgestellt, dass es bei TDD nicht immer der Fall ist, dass in Unit Tests eine 1: 1 Beziehung zwischen Klassen und Tests besteht. Wenn Sie das tun, werden Sie eine harte Zeit haben, um zu refactoring. Nach einem Refactoring erhalte ich normalerweise etwa 50% 1: 1 Kopplungen und 50% Tests, die Sie mit mehreren Klassen oder Gruppen von Tests verknüpfen können, die mit einer einzelnen Klasse verbunden sind.

Integrationstests finden statt, wenn Sie versuchen zu beweisen, dass etwas funktioniert oder nicht. Dies geschieht entweder, wenn Sie sich Sorgen machen, weil Sie etwas liefern müssen, oder wenn Sie einen Fehler finden. Der Versuch, aus Integrationstests die volle Abdeckung zu erhalten, ist (um es gelinde auszudrücken) eine schlechte Idee.

Das Wichtigste ist, dass ein Test eine Geschichte erzählen muss. In BDD'schen Begriffen: Wenn man so etwas hat, sollte das passieren. Die Tests sollten Beispiele dafür sein, wie Sie beabsichtigen, Benutzer die Einheit, API, Anwendung, Service, ... zu verwenden.

Die Granularität und Organisation Ihrer Tests folgt aus Ihrer Geschichte. Es sollte nicht mit simplen Regeln im Voraus entworfen werden.

Answer 5

Ich würde mit der Antwort von f4 übereinstimmen. Solche Tests (Level höher als UT) haben normalerweise keine Korrelation mit bestimmten Klassen. Ihre Tests sollten sich an die Projektanforderungen und Spezifikationen halten.

Für den Fall, dass Sie wirklich ein Testprojekt entwickeln müssen, das auf Ihre Testanforderungen zugeschnitten ist, würde ich den folgenden Ansatz empfehlen: ein separates Projekt mit Paketen pro Anforderung oder User Story (abhängig von Ihrem Ansatz zur Verwaltung der Anforderungen). Zum Beispiel:

 
src/itest 
    -package1 - corresponds to story#1 
    -classA - test case1 
    -classB - test case2 
    -package2 - corresponds to story#1 
    -classC - test case2 
    -packageData - your common test data and utilities 

jedoch im Auge behalten - eine Integration oder System-Level-Tests zu tun ist in der Regel komplizierte Aufgabe und ihr Umfang leicht breiter sein könnte Software-Projekt als Prüfung abdecken kann. Sie sollten bereit sein, Testautomatisierungstools von Drittanbietern in Betracht zu ziehen, da es auf der Ebene der Integration oder des Systemtests oft ein effizienterer Ansatz ist, als ein maßgeschneidertes Testpaket zu entwickeln.