Dois-je séparer les tests unitaires et les tests d'intégration?

Je dois écrire des tests unitaires et des tests d'intégration pour un projet.

Tous les tests doivent-ils être placés dans un dossier de tests unique ?
Ou les tests unitaires et les tests d'intégration devraient-ils chacun se trouver dans un dossier de tests distinct ?
Ou devrais-je même les mettre dans des projets séparés ?

Si je les garde ensemble, y a-t-il des avantages ou des inconvénients à cette approche?

architecture unit-testing integration-tests

— Ahmed Ragheb
source

Si vous travaillez dans un environnement CI, l'important est qu'ils puissent être facilement identifiés (par attribut, etc.) car les tests d'intégration ne s'exécutent pas toujours sur le serveur de génération.

— Robbie Dee

Connexes: Test: unité vs intégration vs autres, quel est le besoin de séparation?

— mouviciel

En général: oui, vous devez placer les tests d'intégration et les tests unitaires dans différents dossiers. Souvent, les programmeurs ne tracent pas une ligne claire entre ces deux types de tests et écrivent simplement tout type de test utile. Mais les tests d'intégration ont tendance à être plus lents, car ils impliquent souvent:

Requêtes de base de données
Demandes de réseau
Comportement dépendant du temps
De grandes quantités de données

En revanche, un test unitaire se moquerait de toute opération coûteuse, de sorte que les tests unitaires ont tendance à s'exécuter rapidement (en fait, la partie la plus lente de l'exécution du test est souvent le cadre de test lui-même).

Lorsqu'un programmeur travaille sur le système, il est dans un cycle d'édition-test. Plus ils obtiennent de rétroaction de test rapidement et plus le cycle est court, plus ils peuvent être productifs. Donc là, nous voulons seulement exécuter des tests importants qui se terminent rapidement. La suite de tests complète ne serait exécutée que dans le cadre d'un processus d'assurance qualité, par exemple sur un serveur CI.

Cela signifie que les grandes suites de tests doivent être classées. Pouvons-nous sélectionner uniquement des tests unitaires pour un composant particulier? Pouvons-nous exclure les tests lents? Une façon simple de le faire est de maintenir différentes suites de tests dans différents répertoires. Si vous n'avez que très peu de tests, un seul répertoire serait également OK tant qu'un programmeur peut facilement sélectionner un sous-ensemble de tests.

Tout ce qui permet à un programmeur d'obtenir rapidement des commentaires est bon. La suite de tests la plus complète n'a pas d'importance si elle n'est pas exécutée régulièrement.

Lectures complémentaires:

Test: unité vs intégration vs autres, quel est le besoin de séparation? qui a été lié par mouviciel ci-dessus.
Dois-je séparer les tests unitaires des tests d'intégration? sur mon blog, qui traite de cette réponse un peu plus en détail.

— amon
source

Lors de la séparation des dossiers, conservez-vous chacun d'eux dans le même package que le code de production (afin de pouvoir tester les méthodes protégées)? Exemple, vous créez un module maven pour les tests unitaires et un autre module maven pour les tests d'intégration. Comme ça, vous pouvez les séparer et toujours tester facilement les méthodes protégées.

— ihebiheb

@ihebiheb En Java, l'utilisation de la visibilité des packages est assez mal vue. Dans certains cas, il peut être utile de l'utiliser et d'accéder à ces API à partir de tests unitaires. Mais en général, ce n'est pas nécessaire. Les tests de style d'intégration n'ont jamais besoin d'accéder aux membres du package privé. La décision de placer ou non les tests dans un projet Maven distinct dépend de la manière dont vous souhaitez les exécuter et les déployer. Je ne suis pas trop dans Java / Maven pour pouvoir vous dire ce qui est sensé ici.

— amon