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
la source
la source
Tests != Test DataRéponses:
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.
la source
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".la source
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.
la source
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.
la source