Classe en cours de test MyClass.Java JUnit alternatives de nom de cas de test:
TestMyClass.Java
MyClassTest.Java
http://moreunit.sourceforge.net semble utiliser "Test" comme préfixe par défaut mais j'ai déjà vu les deux utilisations. Les deux semblent être reconnus lors de l'exécution de l'ensemble du projet en tant que test unitaire dans Eclipse, car ce sont les annotations à l'intérieur des classes qui sont analysées pour @Test. Je suppose que Maven fait la même chose.
Lequel est préféré?
Un autre argument pour le suffixe - au moins en anglais:
Une classe représente généralement un nom , c'est un modèle de concept. Un exemple de l'un de vos tests serait un "test MyClass". En revanche, une méthode modéliserait une sorte d’action, telle que 'tester [la] calculer [méthode]'.
Pour cette raison, j'utilisais toujours le 'suffixe' pour les classes de test et le préfixe pour les méthodes de test:
the MyClass test --> MyClassTest
test the calculate method --> testCalculate()
Je préfère utiliser le suffixe - cela signifie qu'il est plus simple de consulter la liste des fichiers d'un répertoire: vous n'avez pas à ignorer mentalement les quatre premières lettres pour obtenir quelque chose de significatif. (Je suppose que vous avez déjà les tests dans un répertoire différent du code de production.)
Cela signifie également que lorsque vous utilisez Open Type (Ctrl-T) dans Eclipse, vous obtenez en même temps le code de production et son test ... ce qui est également un rappel si vous ne voyez pas voyez une classe de test :)
Avant JUnit 4, il était courant de nommer vos classes de test SomethingTest, puis d'exécuter JUnit sur toutes les classes correspondant à *Test.Java
. JUnit 4 piloté par les annotations, il vous suffit d'annoter vos méthodes de test avec @Test
et de vous en servir. Vos classes de test seront probablement dans une structure de répertoires différente de celle de votre source réelle (source dans src/
classes de test dans test/
), de sorte que les préfixes/suffixes de ces jours sont en grande partie hors de propos.
Je préfère utiliser la syntaxe TestClassName. Lorsque j'utilise l'autre syntaxe, j'ai du mal à identifier le test et la classe dans les éditeurs lorsque les deux sont ouverts. Devoir chercher les quatre dernières lettres du nom est fastidieux et ces lettres ne sont pas toujours affichées.
Pour moi, l’autre syntaxe conduit à plusieurs permutations incorrectes entre les fichiers tous les jours, ce qui prend du temps.
Je ne veux offenser personne, mais je pense qu’il est juste de dire que "moreunit" est beaucoup moins connu que JUnit, qui est à peu près omniprésent, et a établi la convention des classes de test suffixantes "Test".
Bien que JUnit4 se soit débarrassé de la nécessité de suivre les conventions de dénomination de classe et de méthode (resp. "Postfix Test" et "prefix test"), je pense que les deux sont toujours utiles pour la clarté.
Imaginez l'horreur d'avoir src/test/Java /.../MyClass.myMethod () testé par src/main/Java /.../MyClass.myMethod () ...
Parfois, il est utile de s'écarter des conventions JUnit3 - Je trouve que nommer les méthodes de configuration après leur travail ("createTestFactory ()") et les annoter "@Avant" est beaucoup plus clair que le générique "setUp ()".
Ceci est particulièrement utile lorsque plusieurs actions de configuration non liées doivent être effectuées - elles peuvent faire l'objet de méthodes distinctes, chacune étiquetée @Avant. Cela communique très bien l’indépendance des actions.
Je pense qu'il est important que vous soyez à l'aise avec vos tests si vous travaillez seul. Mais si vous êtes dans un groupe, vous feriez mieux de vous asseoir et de réparer quelque chose. Personnellement, j'ai tendance à utiliser le suffixe pour les classes et le préfixe pour les méthodes et à essayer d'adapter mes groupes à cette convention.
J'utilise également MyClassTest_XXX lorsque je souhaite diviser mon test en plusieurs classes. Ceci est utile pour tester une grande classe et je veux que les tests soient logiquement groupés. (Je ne peux pas contrôler le code hérité, ce scénario se présente donc.) J'ai quelque chose comme KitchenSinkTest_ForArray, KitchSinkTest_ForCollection, etc.
Je suggère MyClassTests
.
Les classes doivent être des expressions nominales, si couramment utilisées MyClassTest
et moins courantes MyClassTests
ou MyClassTestCase
ou MyClassTestFixture
tout le travail Techniquement, une instance d'une classe de test JUnit représente un test fixture , mais TestFixture
est un peu trop détaillé pour moi.
Je pense que MyClassTests
exprime l'intention de la meilleure façon possible car il existe généralement plusieurs méthodes de test dans une classe, chacune représentant un seul test (scénario de test).