Où dois-je stocker les données de test?

J'ai des tests unitaires plus petits qui utilisent de petits extraits de jeux de données réels. Je voudrais également tester mon programme par rapport à des ensembles de données complets pour une multitude de raisons. Le seul problème est qu'un seul ensemble de données réel fait environ 5 Go. Je n'ai pas trouvé de chiffres précis pour ce que les référentiels Git peuvent stocker, mais cela semble trop.

Selon ce poste des programmeurs, je devrais conserver toutes mes données nécessaires pour tester le projet dans le référentiel.

La solution que mon équipe a adoptée est que le projet a un fichier qui contient un chemin vers un système de fichiers connecté au réseau qui contient nos données de test. Le fichier est ignoré par Git.

J'ai l'impression que c'est une solution imparfaite pour deux raisons. Lorsque le NAS ne fonctionne pas, est lent ou est en panne, nous ne pouvons pas exécuter un test complet. La deuxième raison est que lorsque quelqu'un clone un référentiel pour la première fois, les tests unitaires échouent et doivent donc trouver comment monter les choses avec un certain nom et la syntaxe utilisée pour créer le fichier de chemin de test.

Ma question est donc double. Combien de données sont trop de données à stocker dans le contrôle de révision?

Quelle est la meilleure façon de gérer de grandes quantités de données de test?

Comment gérer des fichiers volumineux dans une chaîne de génération

J'aime utiliser un outil de construction qui gère la dépendance - comme maven ou gradle. Les fichiers sont stockés dans un référentiel Web et l'outil prend en charge le téléchargement et la mise en cache de manière automatique lorsqu'il rencontre la dépendance. Il élimine également la configuration supplémentaire (configuration NAS) pour les personnes qui souhaitent exécuter le test. Et cela rend le rafraîchissement des données assez indolore (il est versionné).

Ce qui est trop gros pour mettre en contrôle de révision

Il y a une grande zone grise. Et si vous décidez que quelque chose n'appartient pas à un RCS, quelles sont vos alternatives? C'est une décision plus facile si vous limitez vos choix entre le RCS et un repo binaire (style maven).

Idéalement, vous ne voudriez que les éléments RCS qui sont modifiables humainement, modifiables ou où vous souhaitez suivre l'historique. Tout ce qui est le produit d'une construction ou d'une autre sorte d'automatisation n'y appartient certainement pas. La taille est une contrainte, mais pas la principale - un fichier source géant (mauvaise pratique) appartient définitivement au contrôle de source. Un petit binaire compilé ne fonctionne pas.

Soyez prêt à faire des compromis pour la commodité des développeurs.

Lorsque le NAS ne fonctionne pas, est lent ou est en panne, nous ne pouvons pas exécuter un test complet.

Évidemment, cela ne peut être résolu qu'en copiant les 5 Go du NAS sur votre disque local. Mais il n'est pas nécessaire de le faire manuellement.

La deuxième raison est que lorsque quelqu'un clone un référentiel pour la première fois, les tests unitaires échouent et doivent donc trouver comment monter les choses avec un certain nom et la syntaxe utilisée pour créer le fichier de chemin de test.

Vous pouvez fournir un script shell simple qui fait exactement cela - montez le NAS avec un certain nom et copiez les données sur votre disque local lorsqu'il n'est pas déjà là, ou lorsque l'ensemble de données sur le NAS est plus récent que l'ensemble de données local. Assurez-vous que le script s'exécutera automatiquement pendant la phase d'initialisation de vos tests unitaires.

Bien sûr, lorsqu'il n'y a pas seulement un de ces ensembles de données, mais tout un tas de dépendances à des fichiers externes en dehors de votre référentiel de code source, alors un outil comme ceux mentionnés par @ptyx pourrait être la meilleure solution.

... quand quelqu'un clone un référentiel pour la première fois, les tests unitaires échouent donc ils doivent comprendre comment monter les choses avec un certain nom et la syntaxe utilisée pour construire le fichier de chemin de test.

Tout d'abord, juste pour avoir une terminologie cohérente: ce type de test (grandes dépendances externes, données réelles) n'est généralement pas considéré comme un test unitaire, mais plutôt comme un test d' intégration ou de système .

Sur le plan pratique: je trouve que c'est une bonne pratique de garder les tests unitaires et d'intégration séparés , car ils ont des forces et des faiblesses différentes.

• séparer les deux types de tests dans le code (convention de nommage, projet séparé, ...)
• fournir un moyen d'exécuter une seule des deux suites de tests
• exécuter uniquement les tests unitaires lors des builds normaux
• exécuter les tests d'intégration à la demande et sur un serveur CI (intégration continue)

De cette façon, les builds locaux sont rapides et fiables (peu ou pas de dépendances externes), et les tests d'intégration sont gérés par le serveur costaud CI. Cela évite le problème que vous décrivez.

Pour savoir comment conserver les données:

Une bonne option est une sorte de gestion des artefacts comme le décrit la réponse de ptyx. Un autre serait de placer les données de test dans un référentiel séparé . De toute façon, les données ne sont pas publiées avec la version principale, et avoir un référentiel séparé évite de forcer tout le monde à récupérer les données de test avec le code source. En d'autres termes, utilisez un deuxième dépôt comme gestion de votre artifacdt :-).