Créer des tests unitaires sans les exporter avec l'API

Question

Je suis nouveau dans le test unitaire avec nunit (et le développement Java en général). Lors de la création de tests unitaires pour des méthodes privées sur des classes, il semble que le fichier de test doit être dans le même package que la classe en cours de test. Quel est le moyen typique d'éviter l'exportation des API des tests unitaires? Puis-je protéger les classes / méthodes de test du package? Ou les développeurs ont-ils généralement une version distincte pour la version qui exclut les fichiers de test unitaire?

Answer 1

Le fichier de test ne doit pas nécessairement se trouver dans le même package que la classe en cours de test. En fait, il est recommandé de regrouper les fichiers de test dans un package complètement séparé, ce qui leur permet de tester l'API publique sans se préoccuper des détails de la mise en œuvre au niveau du package.

Vous pouvez également configurer votre script de génération (par exemple, Nant) pour ignorer les fichiers contenant le mot-clé "Test". lorsque vous construisez votre version exécutable.

Answer 2

Je peux dire à IntelliJ ou Ant de ne pas empaqueter les tests JUnit dans le déploiement. J'ai des tests dans un répertoire séparé du code source, ce qui le rend possible.

Ne mélangez pas la source et testez les classes ensemble. Gardez-les séparés pour faciliter le déploiement de l'outil / script que vous utilisez.

Answer 3

Personnellement, mon approche consiste uniquement à tester les fonctionnalités exposées. Vous ne testez donc que des pièces bien encapsulées.

Cela amène généralement ma conception à contenir de petites classes avec des fonctionnalités bien définies, faciles à tester.

En général, lorsque vous testez des unités, vous ne devez pas vous préoccuper des éléments internes de ce que vous testez. Je trouve donc que c'est la meilleure façon de l'aborder.

Je conviens également qu'il est préférable de séparer le code de test et de production.

Answer 4

Conservez le code source du test en dehors du code source de l'application. En général, testez uniquement les fonctionnalités exposées. Si vous avez vraiment besoin de tester le comportement privé, créez un objet de test qui étend l'objet réel et permet à publec d'accéder au comportement privé.

Answer 5

Je pense que c'est une erreur de déplacer votre code de test hors du package de CUT (Class Under Test). À un moment donné, vous voudrez peut-être tester une méthode ou une classe protégée, et avoir votre code de test dans un autre package rend cela difficile, voire impossible.

Une meilleure solution consiste à créer un répertoire distinct pour votre code de test, qui reflète simplement la structure de package de votre code de production. Voici ce que je fais:

src/main/java/com/example/Foo.java
src/test/java/com/example/FooTest.java

Ensuite, votre script de construction peut très simplement ignorer src / test / ** au moment de la création du package et du déploiement.