Existe-t-il un framework de test unitaire Java qui teste automatiquement les getters et les setters? [fermé]

https://stackoverflow.com/questions/108692

01-07-2019
|

Question

Il existe un débat bien connu en Java (et dans d’autres communautés, j'en suis sûr) sur le point de savoir si les méthodes getter / setter triviales doivent être testées. Cela concerne généralement la couverture de code. Convenons qu'il s'agit d'un débat ouvert et n'essayons pas d'y répondre ici.

Plusieurs articles de blog sur l'utilisation de la réflexion Java pour tester automatiquement de telles méthodes.

Un framework (par exemple, jUnit) fournit-il une telle fonctionnalité? par exemple. Une annotation indiquant que "ce test T devrait tester automatiquement tous les getters / setters de la classe C, car j’affirme qu’ils sont standard".

Il me semble que cela apporterait une valeur ajoutée. S'il était configurable, le "débat" resterait une option pour l'utilisateur.

La solution

Unitils le fait avec la méthode statique assertRefEquals .

Autres conseils

Je ne suis au courant d'aucune bibliothèque ou classe facilement disponible qui effectue cela. C'est peut-être principalement parce que je m'en fiche, car je suis du côté de la forte opposition à de tels tests. Donc, même si vous l'avez demandé, il faut avoir un peu de justification pour cette vue:

Je doute que la qualité de votre code ou votre couverture soit bénéfique pour les getters et les régleurs automatiques: ces méthodes sont utilisées à partir d'un autre code (et y sont testées, par exemple couvertes à 100%) ou ne sont pas utilisées du tout (et peuvent être supprimées). En fin de compte, vous laisserez les accesseurs et les installateurs car ils sont utilisés depuis le test, mais nulle part ailleurs dans l'application.

Il devrait être facile d’écrire un tel test, par exemple. avec Apache Commons BeanUtils, mais je doute que vous en ayez vraiment besoin si vous avez de bons tests sinon.

J'ai créé le projet OpenPojo pour résoudre ce problème exact .

Le projet vous permet de valider:

Appliquer la norme de codage Pojo (c'est-à-dire tous les champs privés ou aucune variable native, etc.)
Applique le comportement Pojo (c'est-à-dire que le configurateur effectue un réglage JUST, aucune transformation, etc.)
Valider l'identité Pojo (c'est-à-dire utiliser une égalité et une génération de hashcode basées sur des annotations)

Voir le didacticiel

Dans la plupart des cas, setter et getter ne font plus que définir et obtenir un champ interne. Un objet doit vérifier les règles internes qu'il ne contient que des valeurs valides. Par exemple

des valeurs nulles sont-elles possibles?
des chaînes vides sont-elles possibles?
ou des valeurs négatives?
ou une valeur nulle?
ou les valeurs d'une liste sont-elles valides?
ou y a-t-il une valeur maximale?
ou existe-t-il une précision maximale sur les valeurs BigDecimal?

Le test unitaire doit vérifier si le comportement est correct s'il existe des valeurs non valides. Cela ne peut pas être automatisé.

Si vous n'avez pas de logique sur le setter ni sur le getter, vous devez l'utiliser partout dans votre application. Ecrivez un test où votre objet est un paramètre pour un test plus complexe. Vous pouvez ensuite le tester avec différentes valeurs de la liste.

Testez votre logique métier et non le getter et le setter. Le résultat devrait également couvrir le getter et le setter. Les méthodes devraient être n'importe quel résultat dans votre logique métier, même si vous n'avez qu'une bibliothèque publique. Si le getter et le setter n'ont aucune couverture de code, supprimez-le.

J'ai fait quelque chose comme ça. Une classe java simple qui prend un objet et teste tous les méthodes de lecture et d’affectation. http://sourceforge.net/projects/getterandsetter/

Je pense que vous devriez éviter autant que possible les méthodes d'obtention et de définition, mais tant qu'elles sont présentes et qu'il faut deux lignes pour les tester, c'est une bonne chose à faire.

Je privilégierai la conception OO à la couverture de code et verrai si je ne peux pas déplacer ces champs dans la classe qui en a besoin. J'essaierais donc de voir si ces accesseurs et ces régleurs peuvent être supprimés, comme suggéré précédemment. les getters et les setters sont briser l'encapsulation .

Je suppose que cette bibliothèque est la réponse à votre question

il teste toutes les valeurs initiales du bean, les setters , les getters , hashCode (), equals () et toString () . Il suffit de définir une carte des propriétés / valeurs par défaut et non par défaut.

Il peut également tester les objets qui sont des beans avec des constructeurs autres que ceux par défaut.

J'essaie openpojo

J'ai botté les pneus et il semble faire le travail.

Il vous permet de vérifier tous les pojos de votre projet.
Il semble vérifier les meilleures pratiques en matière de pojo

Consultez ce tutoriel pour un démarrage rapide Didacticiel

Réponse au commentaire précédent sur @ me ici à cause de ma réputation:

Vlookward, ne pas écrire de getters / setters n’a aucun sens. La seule option permettant de définir des champs privés consiste à définir des paramètres explicites, à les définir dans votre constructeur ou à définir le paramètre indirectement via d'autres méthodes (report fonctionnel du programme de sélection à un autre endroit). Pourquoi ne pas utiliser de setters?

Eh bien, parfois, il n’est pas nécessaire que le champ soit privé (désolé si mon anglais n’est pas très bon). Souvent, nous écrivons notre logiciel car il s’agissait d’une bibliothèque et encapsulons nos champs (nos champs de logique métier) avec des getters / setters inutiles.

D’autres fois, ces méthodes sont réellement nécessaires. Ensuite, il y a deux possibilités:
1. Il y a une logique commerciale à l'intérieur d'eux. Ensuite, ils devraient être testés, mais ils ne sont pas de vrais Getters / Setters. J'écris toujours cette logique dans d'autres classes. Et les tests vérifient que d’autres classes, pas le POJO .
2. Il n'y a pas. Ensuite, ne les écrivez pas à la main, si vous le pouvez. Par exemple, une implémentation pour la prochaine interface peut être entièrement générée automatiquement (et également au runtime!):

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

Alors, testez uniquement ce qui est écrit à la main. Peu importe si c'est un getter / setter.

Je n'écris pas de cas de test pour chaque propriété, mais teste plutôt tous les setters / getters d'un seul cas de test en utilisant réflexion / introspecteur pour déterminer le (s) type (s). Voici une excellente ressource qui montre ceci:

http://www.nearinfinity.com/blogs/scott_leberknight/do_you_unou_test_gett / a>

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow