Les données de test doivent-elles être archivées dans le contrôle de version?

40

J'écris un code de test pour une fonctionnalité qui traite les fichiers PDF. L'idée de base des tests est que je les pointe vers certains fichiers PDF spécialement sélectionnés, qu'ils les traitent et que je vérifie que le résultat obtenu correspond à mes attentes.

Ma question est la suivante: où devrais-je stocker ces PDF de grande taille? Devrais-je les vérifier dans le contrôle de version avec le code? Ou les mettre ailleurs? De toute évidence, le code de test est inutile sans les fichiers PDF (ou même avec des fichiers PDF différents), mais néanmoins, les placer dans notre référentiel semble être une mauvaise chose.

testing version-control data

— Swiftheart
source

2

doublon possible de Les tests unitaires doivent-ils être stockés dans le référentiel?

— un CVn

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey

4

@ RobertHarvey C'est vrai, mais si les données de test sont nécessaires au bon fonctionnement du test, j'estime que cela devrait être considéré comme faisant partie du test. C’est aussi l’approche adoptée par les trois réponses jusqu’à présent, telle que je les comprends.

— un CVn

84

Votre système de contrôle de version doit contenir tout ce dont il a besoin pour créer, compiler, tester et conditionner une application en vue de sa distribution (par exemple, MSI, RPM). Je dirais également que les configurations de construction et les autres scripts doivent également être sous contrôle de version.

Je devrais pouvoir extraire un projet et disposer d'un environnement complet de compilation, de développement et de test.

Il existe deux approches pour vérifier les données de test. Tout d'abord, vous pouvez archiver les données de test elles-mêmes (PDF dans ce cas). Deuxièmement, vous pouvez archiver des données source pouvant être utilisées pour générer des données de test (le cas échéant). Il peut s’agir d’un script SQL chargé dans une base de données vierge contenant des données de test ou d’un fichier texte pouvant être compilé au format PDF ou autre.

D'autres peuvent ne pas être d'accord avec l'intégration de tout dans le contrôle de version, mais j'ai découvert dans mon expérience professionnelle qu'il est essentiel de garantir la reconstruction d'un environnement complet.

20

Oui. Absolument oui. Nous sommes en 2014, rien ne justifie l'utilisation d'un contrôle de révision qui ne gère pas les fichiers binaires de manière transparente.

— Kilian Foth

4

Je suis d'accord, mais vous voulez absolument éviter la situation dans laquelle vous archivez également des objets indésirables. Par exemple, si les données de test incluent un dossier "sortie" contenant tous les fichiers pdf générés par les tests, vous voudrez alors ne pas l'inclure dans le référentiel. Mais je conviens que les tests eux-mêmes devraient faire partie du référentiel, ainsi que de tous les packages nécessaires à son exécution.

— Kenneth Garza

1

@ KennethGarza Ce n'est pas difficile, vraiment. En règle générale, tout contenu original (code source, code source du test, données de test, support, documentation [réelle], bibliothèques tierces, scripts de compilation, scripts d’outils, scripts de conversion, etc.) doit être inclus, tandis que toutes les données qui peuvent être générés dans un délai raisonnable à partir des données d'origine ne devrait pas l'être. De plus, étant donné que ce sont les résultats des tests, ils n'ont probablement de sens que si vous les exécutez vous-même, sinon vous ne testez pas votre programme, vous testez la capacité du logiciel VCS à préserver l'intégrité de vos fichiers :)

— Thomas

1

@ MarnenLaibow-Koser: un projet sur lequel j'ai travaillé pour détecter une défaillance électrique dans les sondes de pacemaker implantées avait une suite de tests de plus de 40 Go. Il n’existe pas de VCS où traiter avec cela n’est pas odieux. Avoir deux pensions est un problème administratif, mais cela peut parfois être le meilleur choix.

— Whatsisname

1

@ MarnenLaibow-Koser vous l'avez. Les tests d'intégration sont dans un référentiel séparé et si l'utilisateur souhaite l'exécuter localement, la gestion des dépendances lui récupère le fichier zip et le décompresse. Habituellement, le serveur / la batterie d’intégration continue est chargé de réaliser le test d’intégration et empêche la fusion des fonctionnalités jusqu’à ce que les tests d’intégration soient réussis.

— user482745

15

Si les tests sont inutiles sans les fichiers d'installation que vous avez préparés, il est logique d'inclure les fichiers dans votre VCS avec le code de test.

Bien que les fichiers utilisés dans le test ne soient pas du code, vous pouvez les voir comme une dépendance sur laquelle repose le code. Il y a donc un intérêt à tout garder ensemble.

En revanche, certains VCS ne gèrent pas bien les gros fichiers binaires et d’autres sont fortement opposés à l’inclusion d’un fichier binaire dans un VCS. Si l'un ou l'autre de ces cas vous concerne, il serait également judicieux de stocker les fichiers de test dans un emplacement bien connu et facilement accessible.

J'envisagerais également d'insérer dans le code de test un commentaire indiquant "compter sur foo.pdfafin d'exécuter tous les tests".

Je ne vois aucun inconvénient à ce que les tests vérifient les données de test. S'ils ne sont pas trouvés, essayez de les obtenir (par exemple, à partir d'une URL) et échouons s'ils ne fonctionnent pas. Faire confiance au réseau est une mauvaise idée car cela rend les tests plus lents et plus fragiles; mais essayer est moins fragile qu'autrement et obtenir automatiquement (et mettre en cache localement) les bonnes données est plus rapide que de lire manuellement les documents / commentaires, de les obtenir et de les mettre en place.

— Warbo

7

S'il s'agit de données statiques, alors oui, mettez-les dans le contrôle de version. Ces fichiers ne changeront pas vraiment une fois qu'ils seront archivés; ils seront soit supprimés si cette fonctionnalité n'est plus nécessaire, soit de nouveaux fichiers de test seront ajoutés à côté. De toute façon, vous n'avez pas à vous soucier des pauvres différences binaires prenant de la place.

Si vous générez des données de test, par exemple. de manière aléatoire, alors vous devriez le sauvegarder automatiquement quand un test échoue, mais le rejeter autrement. Toutes les données sauvegardées de cette manière doivent être transformées en tests de régression réguliers, afin que ces cas extrêmes soient définitivement testés à l'avenir au lieu de compter sur la chance du tirage au sort.

— Warbo
source

2

Si vous générez des données de test de manière aléatoire, vous devriez vraiment acheter un livre sur la rédaction de tests automatisés reproductibles.

— Dawood dit réintégrer Monica

5

@DavidWallace Vous dites donc que des champs entiers tels que le test fuzz, la vérification des propriétés et les tests de logiciels statistiques sont non seulement faux, mais nuisibles?

— Warbo

5

@DavidWallace random! = Non reproductible.

— congusbongus

5

@DavidWallace vous pouvez l'appeler comme vous voulez alors. Données de test aléatoires, enregistrement des entrées, recyclage si nécessaire, ergo reproductible. Ne mène pas à un monde de blessé.

— congusbongus

2

@DavidWallace "au lieu de penser uniquement aux tests nécessaires" ne veut pas dire "pas de test aléatoire", cela signifie "pas seulement des tests aléatoires". En ce qui concerne "vous ne pouvez pas reproduire les données qui ont trouvé le bogue", avez-vous lu la réponse que vous commentez? ;)

— Warbo

0

Incluez certainement ces données avec vos tests et votre code d'application principal. Il est utile d’avoir une suite de tests vraiment bien organisée. Ainsi, si vous testez l’extraction de pdf (et que votre code est bien encapsulé), vous devriez pouvoir créer un chemin vers vos données de test, en fonction du chemin vers le code de l’application. - ça a toujours fonctionné pour moi.

Avec git, vous pouvez configurer un fichier .gitignore pour empêcher toute sortie temporaire ou tout test de journalisation de polluer votre référentiel.

— NickJHoran
source