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

50

Je suis un programmeur en pleine croissance qui met enfin en pratique les tests unitaires pour une bibliothèque que je stocke sur GitHub.

Je me suis dit que je pourrais peut-être inclure les suites de tests dans le référentiel, mais lorsque je regarde 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?

version-control unit-testing

— parisminton
source

13

Pourquoi pas? Les tests doivent venir avec le projet ou ils sont à peine inutiles.

61

Le fait que certains projets n'incluent pas de tests unitaires dans leur référentiel est probablement dû à la non-existence de ces tests au départ.

— Prasopes

4

Ils sont construits séparément, mais sinon, les tests u sont étroitement associés au code. Pour assurer la cohérence, il faut une sorte de gestion de la dépendance. Qu'il s'agisse de les placer dans le même référentiel, sous-référentiel ou de maintenir la version contrôlée "lien" pour tester le référentiel, etc.

— MaR

2

@stoupa a tout à fait raison: ce serait bien d'assumer le meilleur, qu'il existe une merveilleuse mémoire cache de tests cachée quelque part, mais dans le monde réel, les programmeurs sont paresseux.

— Cascabel

2

Notez que je considérerais comme une bonne idée de désactiver la compilation de classes de test dans votre script de construction.

— user606723

119

Vous devriez absolument mettre vos tests dans le référentiel. À mon avis, les tests font partie du code et peuvent aider les autres à le comprendre (s'ils sont bien écrits). En outre, ils peuvent aider les autres lors des modifications ou des contributions à votre base de code. De bons tests peuvent vous donner l'assurance que vos modifications ne cassent rien par inadvertance.

Le code de test doit cependant ê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-elle partie de la production ou du code de test" ne devrait 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 (du moins lorsque j'utilise une version, bien que des bogues puissent évidemment apparaître). Il offre une certaine couverture de test dans les tests d'intégration, mais cela ne suffit pas.

— ftr
source

1

Comme autre exemple, jetez un coup d’œil au dossier de test d’ipython . Si quelqu'un vérifie, peu importe où ils l'ont mis, les liens relatifs pour les tests sont toujours vrais. Il est facile de le tester, ce qui est important pour déterminer si votre nouvelle machine de développement est configurée correctement.

— Spencer Rathbun

Les tests ne font pas seulement partie du code, ils font également partie de la documentation et font souvent partie des spécifications. Les tests (qui courent et réussissent) sont une "documentation vivante".

— Michael Easter

54

Si vous n'incluez pas les tests unitaires dans le code source enregistré, alors:

comment quelqu'un qui télécharge et construit sa propre copie de ce code va-t-il 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) le sont encore plus, mais elles peuvent certainement arriver, en particulier lorsque vous ne pouvez pas dicter l'environnement de construction l'employeur peut dicter quels outils sont utilisés.
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 bout de ligne, j’envisagerais de ne pas inclure de tests unitaires écrits dans le référentiel officiel du code source, ce qui est une très mauvaise chose.

— un CVn
source

7

Bien sûr, vous devriez mettre 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)

— BЈовић
source

6

S'il y a une chance de les exécuter sur un autre ordinateur, incluez-les définitivement. Ils devraient être construits séparément, de sorte que les utilisateurs ne soient pas obligés de le faire et qu'ils puissent avoir des dépendances supplémentaires, mais ils devraient certainement être 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 d'avoir les tests en tant que module séparé afin que vous puissiez facilement exécuter de nouveaux tests avec un code plus ancien. Cela serait utile pour les tests de bibliothèques stables ou de boîtes noires via une ligne de commande; l'utilité pour les langages compilés où les nouveaux tests ne compileront probablement pas avec un code plus ancien est limitée.

— Jan Hudec
source

5

Absolument. Les points bonus supplémentaires ici sont dans la capacité de suivre que la version X d'un fichier source va avec la version Y d'un test. En d'autres termes, vous devez être en mesure de revenir à une version précédente et d'extraire les tests appropriés conçus pour cette version (en cas de changement ou de modification de l'API).

— anon
source

3

Je viens juste de terminer la lecture de "Brownfield Application Development in .Net" , ce qui fournit d'excellents conseils sur la structure d'une application, y compris le contrôle de la source, 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.

— seanfitzg
source