Sollen Testdaten in die Versionskontrolle eingecheckt werden?

40

Ich schreibe einen Testcode für eine Funktion, die PDF-Dateien verarbeitet. Die Grundidee hinter den Tests ist, dass ich sie auf einige PDFs verweise, die ich speziell ausgewählt habe, sie verarbeite und überprüfe, ob die Ausgabe den Erwartungen entspricht.

Meine Frage ist: Wo soll ich diese großformatigen PDFs speichern? Soll ich sie zusammen mit dem Code in die Versionskontrolle einchecken? Oder woanders hinstellen? Offensichtlich ist der Testcode ohne die PDFs (oder sogar mit anderen PDFs) nutzlos, aber dennoch fühlt es sich falsch an, sie in unser Repository zu stellen.

testing version-control data

— Swiftheart
quelle

2

Mögliches Duplikat von Sollen Komponententests im Repository gespeichert werden?

— ein Lebenslauf vom

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey

4

@RobertHarvey Stimmt, aber wenn die Testdaten erforderlich sind, damit der Test funktioniert, sollte er meiner Meinung nach Teil des Tests sein. Das ist auch der Ansatz, den alle drei Antworten bisher vertreten, soweit ich sie verstehe.

— ein Lebenslauf vom

84

Ihr Versionskontrollsystem sollte alles enthalten, was zum Erstellen, Kompilieren, Testen und Packen einer Anwendung für die Verteilung (z. B. MSI, RPM) erforderlich ist. Ich würde auch argumentieren, Build-Konfigurationen und andere Skripte sollten auch in der Versionskontrolle sein.

Ich sollte in der Lage sein, ein Projekt auszuchecken und eine vollständige Kompilierungs-, Build- und Testumgebung zu haben.

Es gibt zwei Ansätze zum Einchecken von Testdaten. Zunächst können Sie die Testdaten selbst einchecken (in diesem Fall PDFs). Zweitens können Sie Quelldaten einchecken, die zum Generieren von Testdaten verwendet werden können (falls zutreffend). Dies kann ein SQL-Skript sein, das in eine leere Datenbank mit Testdaten geladen wird, oder eine textbasierte Datei, die in eine PDF- oder eine andere Datei kompiliert werden kann.

Andere sind vielleicht nicht einverstanden, alles in der Versionskontrolle zu überprüfen , aber ich habe in meiner beruflichen Erfahrung festgestellt, dass es entscheidend ist, sicherzustellen, dass eine vollständige Umgebung von Grund auf neu erstellt werden kann.

20

Ja. Absolut ja. Es ist 2014, es gibt keinerlei Rechtfertigung für die Verwendung der Revisionskontrolle, die Binärdateien nicht nahtlos verarbeitet.

— Kilian Foth

4

Ich stimme zu, aber Sie möchten auf jeden Fall die Situation vermeiden, in der Sie auch Junk-Artikel einchecken. Wenn die Testdaten beispielsweise einen "Ausgabe" -Ordner enthalten, der alle von den Tests generierten PDF-Dateien enthält, möchten Sie diese nicht in das Repository aufnehmen. Aber ich bin damit einverstanden, dass die Tests selbst Teil des Repos sein sollten, sowie alle Pakete, die benötigt werden, um es auszuführen.

— Kenneth Garza

1

@KennethGarza Es ist nicht wirklich schwer. Als Faustregel gilt, dass alle Originalinhalte (Quellcode, Testquellcode, Testdaten, Datenträger, [echte] Dokumentation, Bibliotheken von Drittanbietern, Build-Skripte, Tooling-Skripte, Konvertierungsskripte usw.) zusammen mit allen Daten enthalten sein sollten das kann in vertretbarer zeit nicht aus den originaldaten generiert werden. Abgesehen davon, dass dies die Testausgaben sind, machen sie wahrscheinlich erst Sinn, nachdem Sie die Tests selbst ausgeführt haben. Andernfalls testen Sie Ihr Programm nicht, sondern die Fähigkeit der VCS-Software, die Integrität Ihrer Dateien zu bewahren. :)

— Thomas,

1

@ MarnenLaibow-Koser: Ein Projekt, an dem ich gearbeitet habe, um elektrische Fehler in implantierten Schrittmacherleitungen zu erkennen, hatte eine Testsuite von über 40 GB. Es gibt kein VCS, bei dem der Umgang damit nicht unangenehm ist. Zwei Repos zu haben ist ein eigener Verwaltungsaufwand, aber manchmal ist es die bessere Wahl.

— Whatsisname

1

@ MarnenLaibow-Koser du hast es geschafft. Integrationstests befinden sich in einem separaten Repository. Wenn der Benutzer es lokal ausführen möchte, ruft das Abhängigkeitsmanagement die Zip-Datei für ihn ab und dekomprimiert sie. Normalerweise wird Continuous Integration Server / Farm mit der Durchführung von Integrationstests beauftragt und verhindert die Zusammenführung von Feature-Zweigen, bis Integrationstests bestanden sind.

— user482745

15

Wenn die Tests ohne die von Ihnen vorbereiteten Setup-Dateien unbrauchbar sind, ist es sinnvoll, die Dateien zusammen mit dem Testcode in Ihr VCS aufzunehmen.

Die im Test verwendeten Dateien sind zwar kein Code, Sie können sie jedoch als Abhängigkeit anzeigen, auf die sich der Code stützt. Es ist also sinnvoll, alles zusammenzuhalten.

Als Kontrapunkt behandeln einige VCSs große Binärdateien nicht gut, und andere lehnen es entschieden ab, irgendeine Art von Binärdatei in ein VCS aufzunehmen. Wenn einer dieser Fälle auf Sie zutrifft, ist es auch sinnvoll, die Testdateien an einem bekannten, leicht zugänglichen Ort zu speichern.

Ich würde auch in Betracht ziehen, einen Kommentar in den Testcode zu schreiben, der besagt, dass man sich darauf verlässt, foo.pdfum alle Tests auszuführen.

Ich sehe nichts falsches daran, dass die Tests nach den Testdaten suchen, wenn sie nicht gefunden werden, versuche ich, sie abzurufen (z. B. von einer URL) und scheitere, wenn sie nicht funktionieren. Sich auf das Netzwerk zu verlassen, ist eine schlechte Idee, da dadurch die Tests langsamer und anfälliger werden. Der Versuch ist jedoch weniger anfällig, und das automatische Abrufen (und Zwischenspeichern) der richtigen Daten ist schneller als das manuelle Lesen von Dokumenten / Kommentaren, das Abrufen und Einrichten.

— Warbo

7

Wenn es sich um statische Daten handelt, dann stellen Sie sie ja in die Versionskontrolle. Diese Dateien werden sich nach dem Einchecken nicht wirklich ändern. Sie werden entweder entfernt, wenn diese Funktionalität nicht mehr benötigt wird, oder es werden neue Testdateien hinzugefügt. In beiden Fällen müssen Sie sich keine Sorgen machen, dass schlechte Binärdifferenzen Platz beanspruchen.

Wenn Sie Testdaten generieren , z. Nach dem Zufallsprinzip sollten Sie es automatisch speichern, wenn ein Test fehlschlägt, aber ansonsten verwerfen. Alle auf diese Weise gespeicherten Daten sollten in regelmäßige Regressionstests umgewandelt werden, damit diese Randfälle definitiv in Zukunft getestet werden, anstatt sich auf das Glück der Auslosung zu verlassen.

— Warbo
quelle

2

Wenn Sie Testdaten zufällig generieren, sollten Sie wirklich ein Buch über das Schreiben reproduzierbarer automatisierter Tests kaufen.

— Laut Dawood wird Monica

5

@DavidWallace Sie sagen also, dass ganze Bereiche wie Fuzz-Tests, Eigenschaftsprüfungen und statistische Softwaretests nicht nur falsch, sondern auch schädlich sind?

— Warbo

5

@DavidWallace zufällig! = Nicht reproduzierbar.

— Congusbongus

5

@DavidWallace Du kannst es dann so nennen, wie Du willst. Zufällige Testdaten, Eingaben aufzeichnen, ggf. recyceln, somit reproduzierbar. Führt nicht zu einer Welt voller Verletzungen.

— congusbongus

2

@DavidWallace "anstatt zu überlegen, welche Testfälle tatsächlich benötigt werden" bedeutet nicht "keine zufälligen Tests", sondern "nicht nur zufällige Tests". Haben Sie die Antwort, die Sie kommentieren, tatsächlich gelesen? ;)

— Warbo

0

Fügen Sie diese Daten unbedingt Ihren Tests und Ihrem Hauptanwendungscode bei. Es ist hilfreich, eine wirklich gut organisierte Testsuite zu haben. Wenn Sie also die PDF-Extraktion testen (und den Code gut gekapselt haben), sollten Sie in der Lage sein, basierend auf dem Pfad zum App-Code einen Pfad zu Ihren Testdaten zu erstellen - das hat bei mir immer geklappt.

Mit git können Sie einen .gitignore einrichten, um zu verhindern, dass temporäre Ausgaben oder Testprotokolle Ihr Repo verschmutzen.

— NickJHoran
quelle