Wo soll ich Testdaten speichern?

Ich habe kleinere Unit-Tests, die kleine Schnipsel aus realen Datensätzen verwenden. Ich möchte mein Programm aus einer Vielzahl von Gründen auch anhand vollständiger Datensätze testen. Das einzige Problem ist, dass ein einzelner realer Datensatz ungefähr 5 GB groß ist. Ich habe keine festen Zahlen für das gefunden, was Git-Repositories speichern können, aber das scheint zu viel zu sein.

Laut diesem Beitrag des Programmierers sollte ich alle meine Daten, die zum Testen des Projekts benötigt werden, im Repository behalten.

Die Lösung, die mein Team übernommen hat, besteht darin, dass das Projekt eine Datei enthält, die einen Pfad zu einem an das Netzwerk angeschlossenen Dateisystem enthält, das unsere Testdaten enthält. Die Datei wird Git ignoriert.

Ich halte dies aus zwei Gründen für eine unvollständige Lösung. Wenn der NAS nicht funktioniert, langsam ist oder ausfällt, können wir keinen vollständigen Test durchführen. Der zweite Grund ist, dass beim ersten Klonen eines Repositorys die Komponententests fehlschlagen, sodass er herausfinden muss, wie Dinge mit einem bestimmten Namen und der zum Erstellen der Testpfaddatei verwendeten Syntax bereitgestellt werden.

Meine Frage ist also zweifach. Wie viele Daten sind zu viele Daten, um sie in der Revisionskontrolle zu speichern?

Was ist ein besserer Weg, um große Mengen an Testdaten zu verarbeiten?

Umgang mit großen Dateien in einer Build-Kette

Ich verwende gerne ein Build-Tool, das Abhängigkeitsmanagement durchführt - wie z. B. Maven oder Gradle. Die Dateien werden in einem Web-Repository gespeichert, und das Tool übernimmt das automatische Herunterladen und Zwischenspeichern, wenn die Abhängigkeit auftritt. Außerdem entfällt die zusätzliche Einrichtung (NAS-Konfiguration) für Personen, die den Test ausführen möchten. Und es macht das Aktualisieren der Daten ziemlich schmerzlos (es ist versioniert).

Was ist zu groß, um die Revisionskontrolle durchzuführen?

Es gibt eine große Grauzone. Und wenn Sie entscheiden, dass etwas nicht in ein RCS gehört, welche Alternativen gibt es dann? Es ist eine einfachere Entscheidung, wenn Sie Ihre Auswahl zwischen dem RCS und einem binären Repo (Maven-Stil) einschränken.

Im Idealfall möchten Sie nur RCS-Inhalte, die von Menschen bearbeitet werden können, flexibel sind oder in denen Sie den Verlauf verfolgen möchten. Alles, was das Produkt eines Builds oder einer anderen Art von Automatisierung ist, gehört definitiv nicht dorthin. Die Größe ist eine Einschränkung, aber nicht die wichtigste - eine riesige Quelldatei (schlechte Praxis) gehört definitiv in die Quellcodeverwaltung. Eine winzige kompilierte Binärdatei tut dies nicht.

Seien Sie bereit, Kompromisse einzugehen, um den Entwicklern Komfort zu bieten.

Wenn der NAS nicht funktioniert, langsam ist oder ausfällt, können wir keinen vollständigen Test durchführen.

Dies kann natürlich nur durch Kopieren der 5 GB vom NAS auf Ihr lokales Laufwerk gelöst werden. Dies muss jedoch nicht manuell erfolgen.

Der zweite Grund ist, dass beim ersten Klonen eines Repositorys die Komponententests fehlschlagen, sodass er herausfinden muss, wie Dinge mit einem bestimmten Namen und der zum Erstellen der Testpfaddatei verwendeten Syntax bereitgestellt werden.

Sie können ein einfaches Shell-Skript bereitstellen, das genau dies tut: Mounten Sie den NAS mit einem bestimmten Namen und kopieren Sie die Daten auf Ihr lokales Laufwerk, wenn es noch nicht vorhanden ist oder wenn das Dataset auf dem NAS neuer als das lokale Dataset ist. Stellen Sie sicher, dass das Skript während der Initialisierungsphase Ihrer Komponententests automatisch ausgeführt wird.

Wenn es nicht nur einen dieser Datensätze gibt, sondern eine ganze Reihe von Abhängigkeiten zu externen Dateien außerhalb Ihres Quellcode-Repositorys, ist ein Tool wie das von @ptyx erwähnte möglicherweise die bessere Lösung.

... wenn jemand zum ersten Mal ein Repository klont, schlagen die Komponententests fehl, sodass er herausfinden muss, wie Dinge mit einem bestimmten Namen und der zum Erstellen der Testpfaddatei verwendeten Syntax bereitgestellt werden.

Erstens, um eine einheitliche Terminologie zu haben: Diese Art von Test (große externe Abhängigkeiten, reale Daten) wird normalerweise nicht als Komponententest, sondern als Integrations- oder Systemtest betrachtet .

Praktisch: Ich halte es für eine gute Praxis, Unit- und Integrationstests getrennt zu halten , da sie unterschiedliche Stärken und Schwächen haben.

• Trennen Sie die beiden Arten von Tests im Code (Namenskonvention, separates Projekt, ...).
• bieten eine Möglichkeit, nur eine der beiden Testsuiten auszuführen
• Führen Sie während normaler Builds nur die Komponententests aus
• Führen Sie die Integrationstests bei Bedarf und auf einem CI-Server (Continuous Integration) aus

Auf diese Weise sind lokale Builds schnell und zuverlässig (geringe / keine externen Abhängigkeiten), und Integrationstests werden vom bulligen CI-Server durchgeführt. Dies vermeidet das von Ihnen beschriebene Problem.

So bewahren Sie die Daten auf:

Eine gute Option ist eine Art Artefaktmanagement, wie es die Antwort von ptyx beschreibt. Eine andere Möglichkeit wäre, die Testdaten in einem separaten Repository abzulegen . Die Daten werden ohnehin nicht zusammen mit dem Haupt-Build veröffentlicht, und durch ein separates Repo wird vermieden, dass jeder gezwungen wird, die Testdaten zusammen mit dem Quellcode abzurufen. Mit anderen Worten, verwenden Sie ein zweites Repo als Artifacdt-Management :-).