10
votes

Préfixe pour les méthodes de test dans l'unité: "Test" vs "devrait"

Il est une pratique courante de préfixer les noms des méthodes de tests en JUnit avec « test ». Mais au cours des dernières années, certaines personnes ont changé cela le préfixe « devrait ».

Si je veux tester la création de clients dans une base de données, je nommerait normalement la méthode « testCustomerCreation ». Cependant, certaines personnes nommeraient "shouldCreateCustomer".

Ceci est beaucoup de goût personnel quand je suis la seule personne dans le projet ou quand tout le monde dans le projet d'accord avec moi. Mais quand / où ce n'est pas le cas, des divergences ou des mélanges incompatibles commence à se manifeste.

Je readed quelque part un article d'un gars qui a nommé ses méthodes comme « testShouldCreateCustomer », et pour cette raison, il a décidé d'abandonner le préfixe « test ». Mais en fait, il n'a pas été préfixant par « test », il utilisait « testShould » et a changé à « devrait ». De toute évidence, cela ne m'a pas convaincu.

Je suis personnellement fortement enclin à coller à préfixe « test » parce que les noms de méthodes commence normalement avec les verbes sous forme infinitif ( « get », « ensemble », « ajouter », « supprimer », envoyer « clair », » », "recevoir", "ouvert", "close", "lire", "écrire", "créer", "liste", "pop", "print", etc, est donc "test"). Ainsi, préfixer un nom de méthode avec « devrait » fait sonner vraiment très étrange pour moi, semble mal.

Alors, quelle est la vraie bonne raison d'utiliser « devrait » au lieu de « test »? Quels sont les grands avantages et les inconvénients?


1 commentaires

Je passerais moins de temps à m'inquiéter de préfixes stupides et de plus de temps à vous inquiéter du reste du nom de test étant descriptif.


5 Réponses :


3
votes

La cohérence est plus importante que d'être correcte sur les problèmes de dénomination. S'il y a une question sur un projet, le membre technique responsable du projet devrait définir les pratiques de codage formellement de manière à ce que des questions telles que cela ne tuent pas de temps précieux sur le projet.


2 commentaires

«La cohérence est plus importante que d'être correcte» - histoire du logiciel ERP de 1,5 million de lignes de mon entreprise dans une phrase.


sur nommer problèmes. Certaines choses méritent de dépenser du temps à discuter et à trouver les meilleures pratiques. En discutant sur le placement de la corset, le schéma de capitalisation et les préfixes de test ne tombent pas dans ce groupe. La généralisation et les conseils mal appliqués peuvent être davantage de la question de votre logiciel.



3
votes

Dans l'original Junit, les méthodes de test devaient commencer test . Beaucoup de cadres pour d'autres langues ont copié cette convention. Même si ce n'est plus le cas dans Junit, et même si d'autres cadres peuvent être différents, je pense que la plupart des programmeurs sont encore assez familiers avec des méthodes nommées par exemple. testx comme étant des tests d'unités, je pense donc qu'il est bon de s'en tenir à la convention pour cette raison.


0 commentaires

20
votes

La convention "Si" devrait "est alignée sur le Développement dirigé par le comportement style de test.

i personnellement vraiment préférer Pour rédiger des tests dans ce style, car il vous encourage à écrire des tests qui lire comme spécifications et sont plus alignés sur le comportement de la classe ou du système que vous testez.

Si possible, je vais parfois une étape plus loin et donnez la classe de test encore plus de contexte en utilisant son nom: xxx

en nommant vos classes et en pensant à Ils dans ce style de spécification, cela peut vous donner beaucoup de conseils sur qui tests à écrire et dans quel ordre vous devez écrire les tests et les rendre verts.

Oui, "Devrait" "test" n'est qu'un préfixe et il est important d'être cohérent, mais cette question concerne également le style et la mentalité de la manière dont vous testez votre code et choisissez les tests à écrire. BDD a une tonne de valeur, alors je suggère de lire plus loin et de l'essayer.


2 commentaires

+1 pour mentionner qu'il s'agit de comportement plutôt que de tester des méthodes


Ok, tu me convaincues. Mais cela signifie que toutes les personnes qui nomment simplement des méthodes de test ne semblent même pas à spécifier (comme «si« devrait », sont des personnes qui ne savent tout simplement pas ce qu'ils font? Si la méthode de test n'a plus rien à voir avec BDD (comme un test qui survient sur un bogue survenu dans une combinaison très particulière de conditions), devrait-il encore être préfixé avec "devrait"?



5
votes

Je dirais que le préfixe "Test" est simplement une maintien des jours de pré-annotation lorsque cela était nécessaire. Je vous suggérerais de simplement utiliser des noms significatifs pour vos étuis de test (et cela peut signifier avec ou sans «test»).

Je préfère nommer la méthode de test afin qu'elle soit claire ce qui est en cours de test. IE P>

checkNullParameter()
runSimpleQuery()
runQueryWithBadParam()


4 commentaires

RunquerywithbadParam () - Vous ne dites pas ce que vous attendez ici. Je préférerais personnellement voir digthrowbadparamexceptiononbadparam (). Devrait également vous encourager à décrire vos attentes ......


L'annotation (attendu = BadparameXception) devrait être suffisamment claire pour le cas simple. Dans d'autres cas, j'ai laissé le code montrer ce que j'attends, car plusieurs affirmations peuvent être faites en ce qui concerne plusieurs paramètres méchants. Par exemple NULL, ou une valeur hors plage de gamme peut être contenue dans le même témoignage (mauvais param). Les affirmations elles-mêmes racontent ce que je m'attends et devraient être clairs pour que quiconque lisait le code.


@Benjamin: Qu'en est-il de Testquerywithbadparam ()? @Robin: Je suis partiellement d'accord. Parfois, "vérifier" ou "vérifier" est meilleur que "test", mais "runsimplequery" n'est pas exactement ce que vous faites. Vous ne l'exécutez pas simplement, vous courez et affirme que cela a été lancé correctement, alors serait comme "TestsimplequeryRun". De même, nous aurions "Testquerywithbadparam". Je sais que cette façon est très probable que chaque méthode aura le test de préfixe, mais ce ne serait pas simplement un préfixe, il fera partie de la description de la méthode.


@Victor - Je pense que @Test TestChisThingthing () est redondant. L'annotation détermine déjà que le but des méthodes est de faire un test. Je ne pense pas avoir le même préfixe sur chaque méthode déjà annotée à être un test est très utile, que ce préfixe soit «test», «devrait» ... ou autre chose.



2
votes

Je préfère le test suffixe. Il est possible que vous puissiez avoir une méthode avec un préfixe de devrait dans votre projet par exemple. Wilbuy et votre test s'appellerait alors testhouldbuy car devait-gaultbuy serait juste très étrange.

J'utilise également le MODUNIT plug-in Eclipse qui créera automatiquement une méthode de test préfixée Avec Test lorsque j'appuie Ctrl + U ou passe à la méthode de test lorsque j'appuyez sur Ctrl + J . (Bien que vous puissiez configurer le préfixe qu'il utilise.) Si vous n'êtes pas cohérent avec votre nommage, des outils automatisés tels que MODUNIT ne seront pas en mesure de vous aider avec vos tests.


1 commentaires

Nommer une méthode d'essai selon la méthode testée doit être évitée après tout, car cela conduisait à refactoriser l'enfer, cet argument n'est donc pas vraiment valable.