JUnit teste les POJO
Je travaille sur un projet où nous devons créer des tests unitaires pour tous nos beans simples (POJO). Est-il utile de créer un test unitaire pour les POJO si ceux-ci sont uniquement constitués de getters et de setters? Est-il prudent de présumer que les POJO fonctionneront environ 100% du temps?
Duplicate of - Est-ce que @Entity Pojos doit être testé?
Voir aussi
La règle dans TDD est "Testez tout ce qui pourrait casser" Est-ce qu'un getter peut casser? Généralement pas, alors je ne me donne pas la peine de le tester. En outre, le code I do test appellera certainement le getter afin que sera testé.
Ma règle personnelle est que je rédige un test pour toute fonction qui prend une décision ou fait plus qu'un calcul trivial. Je n'écrirai pas de test pour i+1, mais je le ferai probablement pour if (i<0)... et certainement pour (-b + Math.sqrt(b*b - 4*a*c))/(2*a).
BTW, l'accent mis sur POJO a une raison différente derrière. Nous voulons que la grande quantité de notre code soit écrite dans des POJO qui ne dépendent pas de l'environnement dans lequel ils s'exécutent . Par exemple, il est difficile de tester les servlets, car elles dépendent de l'exécution dans un conteneur. Nous voulons donc que les servlets appellent des POJO qui ne dépendent pas de leur environnement et sont donc faciles à tester.
Les POJO peuvent également contenir d'autres fonctions, telles que equals (), hashCode (), compareTo () et diverses autres fonctions. Il peut être utile de savoir que ces fonctions fonctionnent correctement.
Je ne pense pas qu'il soit utile de tester de simples getters et setters de propriétés. Le but des tests unitaires n'est pas de vérifier que votre compilateur fonctionne.
Cependant, dès que vous ajoutez un comportement conditionnel, null-check ou tout autre comportement non trivial à vos accesseurs (ou méthodes), je pense qu'il est approprié d'ajouter des tests unitaires.
Une fois, j'ai passé deux heures à cause de quelque chose comme ça:
int getX()
{
return (x);
}
int getY()
{
return (x); // oops
}
Puisqu'il ne faut presque pas de temps pour écrire les tests pour les simples getters, je le fais maintenant par habitude.
J'utilise IntelliJ comme un IDE, et il écrit assez pour moi des POJO triviaux - certainement le constructeur et les getters/setters. Je ne vois aucun intérêt à ce que l’unité teste cela, car tous les bogues figureront probablement dans le code de test que j’écris.
Les tests unitaires non seulement valident que le code fonctionne correctement, mais ils documentent le comportement attendu. Je ne sais pas combien de fois j'ai vu des choses casser, parce que quelque temps plus tard, quelqu'un modifie le comportement d'un getter ou d'un setter dans un POJO, puis il casse inopinément autre chose (par exemple, quelqu'un ajoute une logique au setter que si quelqu'un définit une valeur null sur une chaîne, le configurateur la change en chaîne vide afin que les NPE ne se produisent pas).
Je ne considère pas les tests unitaires sur les POJO de magasins de données comme une perte de temps, je les considère comme un filet de sécurité pour la maintenance future. Cela étant dit, si vous écrivez manuellement des tests pour valider ces objets, vous le faites à la dure. Jetez un oeil à quelque chose comme http://gtcgroup.com/testutil.html
Il existe un utilitaire open source http://meanbean.sourceforge.net/ qui vous permet de tester les POJO. Il existe également une page décrivant les avantages/questions que l’on pourrait avoir sur ce que cet utilitaire offre et pourquoi il devrait être utilisé.
Je ne l'ai jamais fatigué moi-même (encore), mais cela m'a été recommandé.
Ma réponse est que les getters et les setters triviaux ne méritent pas leurs propres tests. Si j'ajoute un code autre que de simples lectures ou écritures, j'ajoute des tests.
Bien sûr, tout cela est normal, vous pouvez donc facilement écrire un script qui génère des tests unitaires pour vos accesseurs et vos traceurs, si vous pensez qu'il y a une quelconque valeur. Certains IDE peuvent vous permettre de définir un modèle qui crée des scénarios de test avec des méthodes de test renseignées pour ce code standard (je pense à IntelliJ ici, mais Eclipse peut probablement le gérer aussi, bien que je n’ai rien fait de tel dans ce IDE).
D'après mon expérience, créer des tests unitaires pour les POJO avec seulement des accesseurs et des setters est tout simplement excessif. Bien sûr, il y a quelques exceptions, s'il y a une logique supplémentaire dans le getter/setter, comme la recherche de null et faire quelque chose de spécial, je créerais un test unitaire pour cela.
De plus, s'il y a un bogue dans le POJO, je créerais un test unitaire pour le prévenir afin que cela ne se reproduise plus.
Cela vaut probablement un test simple pour vous assurer que vous n’avez pas écrit
public void setX(int x) {
x = x;
}
Bien que vous devriez coder pour éviter cela (en mettant un modificateur final sur le paramètre de la méthode, ou similaire). Cela dépend également de la manière dont vous générez vos accesseurs, et s'ils risquent de souffrir d'erreurs de copier/coller, etc. (cela se produira même dans les environnements qui essaient de faire respecter IDE usage - cela se produira).
Mon souci principal avec les classes contenant beaucoup de setters/getters est cependant que fait la classe ? Les objets doivent faire des choses pour vous plutôt que de simplement conserver et renvoyer des données. S'il s'agit d'objets d'entité de données, le modèle de définition/d'acquisition peut être correct. Cependant, le mieux est de définir les données dans l'objet et de lui demander de le manipuler (calculez votre solde bancaire, lancez la fusée, etc.) plutôt que de renvoyer les données et de vous laisser le faire vous-même!
USE LIBRARY: utilise les bibliothèques existantes qui permettent de tester les POJO. Une de ces bibliothèques que j'ai rencontrée est meanbean.
Ref : http://meanbean.sourceforge.net/
Maven : http://mvnrepository.com/artifact/org.meanbean/meanbean (version actuelle: 2.0.3)
IGNOREZ DES POJO: Sonar peut être configuré pour exclure des POJO ou des packages spécifiques à exclure des rapports de couverture de test unitaire. Quelques exemples ci-dessous:
<properties> <sonar.coverage.exclusions> **/domain/**/*, **/pojos/* </sonar.coverage.exclusions> </properties>
J'expérimente avec cobatura pour la couverture de code et je viens de rencontrer le même problème.
Il serait bien d’avoir une annotation à ajouter à la classe qui dit ne pas inclure cette classe dans la couverture de code. Cependant, il est possible de placer votre pojo dans un package séparé, puis d'exclure ce package de l'analyse.
Consultez la documentation en fonction de votre outil, cela fonctionne avec Ant, Maven ou en ligne de commande.
Je viens de commencer un projet pour le faire. sa en phase pré-alpha en ce moment. C'est un plugin Eclipse.
Bien que je convienne que généralement un passeur/acquéreur de POJO n'a pas nécessairement besoin d'un test, je pense qu'il est agréable d'y avoir un test simple car, à mesure que la situation évolue, il vous sera plus facile d'ajouter de nouveaux tests pour les POJO. . Le test unitaire est configuré, les méthodes sont là pour tester le setter/getter, tout ce que vous avez à faire est de gérer la nouvelle complexité.
Cela aide également avec les rapports de couverture de code, ce qui aide à garder les gestionnaires heureux. (Mon entreprise utilise Emma).
Ce problème peut être résolu en utilisant la bibliothèque Lombok qui élimine tout ce code standard, ainsi que le code égal et hashcode.
Donc, vous n'avez pas besoin de les tester sauf si vous avez une exigence spécifique pour les égaux et le hashcode