Séparez-vous vos tests unitaires de vos tests d'intégration? [fermé]

Question

Je me demandais si quelqu'un d'autre considérait les tests d'intégration comme un test unitaire spécial. Cependant, d'autres programmeurs m'ont dit qu'il est judicieux de séparer vos tests unitaires et vos tests d'intégration. Je me demandais si quelqu'un pourrait expliquer pourquoi c'est une bonne idée. Quels avantages y aurait-il à traiter les tests d'intégration et les tests unitaires comme complètement différents? Par exemple, j'ai vu des dossiers et des packages distincts pour les tests d'intégration et les tests unitaires. Je suis d’avis qu’un seul package de test contenant à la fois des tests unitaires et des tests d’intégration serait suffisant, car ils correspondent tous deux au même concept.

Answer 1

Je les considère comme différents pour la raison suivante.

• Les tests unitaires peuvent être effectués sur une seule classe / module dans l'environnement du développeur.
• Les tests d'intégration doivent être effectués dans un environnement similaire à la configuration de production réelle.

Les tests unitaires sont délibérément conservés "légers". afin que le développeur puisse les exécuter aussi souvent que nécessaire, à un coût minimal.

Answer 2

La vitesse est la principale raison. Vous souhaitez que vos tests unitaires soient aussi rapides que possible afin de pouvoir les exécuter aussi souvent que possible. Vous devez toujours exécuter vos tests d'intégration, mais les exécuter une fois avant un enregistrement devrait suffire à l'OMI. La suite de tests unitaires doit être exécutée beaucoup plus souvent, idéalement à chaque refactorisation.

Je travaille dans un environnement où nous avons environ 15 000 tests Junit avec des tests unitaires et d’intégration complètement mélangés. La suite complète prend environ une demi-heure à fonctionner. Les développeurs évitent de l'exécuter et trouvent des erreurs plus tard qu'ils ne le devraient. Parfois, ils s'enregistrent après avoir exécuté seulement un sous-ensemble des tests et incluent un bogue qui interrompt la construction continue.

Commencez tôt la séparation de vos tests. Il est très difficile d'avoir une grande suite une fois.

Answer 3

Oui. Généralement, les tests unitaires sont définis au niveau classe. Ils existent donc dans un environnement avec des objets fictifs. Les tests d’intégration, en revanche, réalisent toutes les astuces en conservant des références à vos types d’assemblage real .

Je ne vois tout simplement pas comment on pourrait organiser à la fois l'unité et l'intégration dans un seul projet.

Answer 4

si vous limitez la notion de "test unitaire" à la portée au niveau de la classe, alors oui, gardez-les séparés

Cependant, si vous définissez la plus petite unité pertinente à tester en tant que fonctionnalité , certains de vos tests "unitaires" seront techniquement des tests "d'intégration"

il est en grande partie inutile de reprendre les différentes définitions / interprétations des termes, cependant, le partitionnement de vos suites de tests doit être fonction de la portée des composants testés et du temps nécessaire pour effectuer le test.

Par exemple, si tous vos tests (unité, intégration, régression ou autre) s'appliquent à un seul assemblage et s'exécutent en quelques secondes, conservez-les tous ensemble. Toutefois, si certains de vos tests requièrent six machines d’installation propres sur un sous-réseau alors que d’autres ne le font pas, il est judicieux de séparer le premier ensemble de tests de ce dernier

résumé: la distinction entre les tests d'unité et d'intégration n'est pas pertinente; suites de tests de paquets basées sur la portée opérationnelle