Les tests unitaires doivent-ils être stockés dans le référentiel?
Je suis un programmeur en pleine croissance qui met enfin en pratique les tests unitaires pour une bibliothèque que je stocke sur GitHub.
Il m'est venu à l'esprit que je pourrais inclure les suites de tests dans le repo, mais en regardant autour d'autres projets, l'inclusion de tests semble aléatoire.
Est-ce considéré comme une mauvaise forme? L'idée est-elle que les utilisateurs ne sont intéressés que par le code de travail et qu'ils vont quand même tester dans leur propre framework?
Vous devez absolument placer vos tests dans le référentiel. Les tests font à mon avis partie du code et peuvent aider énormément les autres à le comprendre (s'ils sont bien écrits). En outre, ils peuvent aider les autres lors de la modification ou de la contribution à votre base de code. De bons tests peuvent vous donner l'assurance que vos modifications ne cassent rien par inadvertance.
Cependant, le code de test doit être bien séparé du code de production. Maven, par exemple, y parvient en plaçant le code de production et de test dans différents dossiers. La question "ce fichier fait-il partie de la production ou du code de test" ne devrait-elle jamais se poser.
Personnellement, je n'écris pas de tests unitaires pour les bibliothèques utilisées dans mon propre code. Je m'attends à ce qu'ils fonctionnent (au moins lorsque j'utilise une version finale, bien que des bogues puissent évidemment apparaître). Il obtient une certaine couverture de test dans les tests d'intégration, mais ce n'est pas suffisant.
Si vous ne pas incluez les tests unitaires dans le code source archivé, alors:
- comment une personne qui télécharge et crée sa propre copie de ce code va-t-elle vérifier qu'il fonctionne comme prévu? Les bogues du compilateur et de la bibliothèque sont rares, et les erreurs de données (en particulier celles qui ne rendent pas le code source impossible à compiler) sont encore plus rares, mais elles sont définitivement peut rogner, en particulier lorsque vous ne pouvez pas dicter la créer un environnement dans la mesure où un employeur peut dicter les outils à utiliser.
- comment allez-vous récupérer les tests si quelque chose arrive à votre copie locale du code source?
- comment un nouveau développeur va-t-il vérifier que ses modifications ne cassent rien dans la base de code existante?
En fin de compte, je considérerais pas y compris tous les tests unitaires écrits dans le référentiel de code source officiel une très mauvaise chose.
Bien sûr, vous devez placer des tests unitaires dans le référentiel, pour plusieurs raisons:
- il est facile de revenir à la version précédente
- d'autres personnes travaillant sur le projet ont également accès à des tests unitaires
- certaines personnes considèrent les tests unitaires comme faisant partie de la documentation (TDD et BDD)
S'il y a une chance de les exécuter sur un autre ordinateur, incluez-les définitivement. Ils doivent être construits séparément, afin que les utilisateurs n'aient pas à le faire, et ils peuvent avoir des dépendances supplémentaires, mais ils doivent être définitivement inclus.
Je soupçonne fortement que la plupart des projets qui n'incluent pas de tests dans le référentiel n'en ont tout simplement pas.
Il peut y avoir une raison pour avoir les tests en tant que module séparé, vous pouvez donc facilement exécuter de nouveaux tests avec du code plus ancien. Il serait utile pour une bibliothèque stable pour l'API ou des tests de boîte noire via la ligne de commande; l'utilité pour les langages compilés où les nouveaux tests ne seront probablement pas compilés avec du code plus ancien est limitée.
Absolument. Les points bonus supplémentaires ici sont dans la possibilité de suivre la version X d'un fichier source avec la version Y d'un test. En d'autres termes, vous devez être en mesure de revenir à une version précédente et de tirer les tests appropriés conçus pour cette version (en cas de changement d'API ou de quelque sorte).
Je viens de terminer la lecture "Brownfield Application Development in .Net" , et cela fournit d'excellents conseils sur la structure d'une application, y compris le contrôle des sources et où/comment/pourquoi inclure des tests unitaires (en particulier dans le domaine de l'intégration continue). Si vous êtes un développeur .Net, je le recommanderais.