Faut-il écrire des tests unitaires pour les getter et setters ?

Question

Sommes-nous censés écrire des tests pour nos getters et setters ou est-ce excessif ?

Answer 1

Je dirais non.

@Will a dit que vous devriez viser une couverture de code de 100%, mais à mon avis, c'est une distraction dangereuse. Vous pouvez écrire des tests unitaires qui ont une couverture de 100%, et pourtant ne tester absolument rien.

Les tests unitaires sont là pour tester le comportement de votre code, d'une manière expressive et significative, et les getters/setters ne sont qu'un moyen d'y parvenir. Si vos tests utilisent les getters/setters pour atteindre leur objectif de tester la "vraie" fonctionnalité, alors c'est suffisant.

Si, d'un autre côté, vos getters et setters font plus que simplement get et set (c'est-à-dire qu'il s'agit de méthodes correctement complexes), alors oui, ils doivent être testés. Mais n'écrivez pas un scénario de test unitaire juste pour tester un getter ou un setters, c'est une perte de temps.

Answer 2

Roy Osherove dans son célèbre livre 'The Art Of Unit Testing' dit :

Les propriétés (getters/setters en Java) sont de bons exemples de code qui ne contient généralement pas de logique et ne nécessite pas de test. Mais attention : dès que vous ajoutez une vérification à l'intérieur de la propriété, vous devez vous assurer que cette logique est testée.

Answer 3

tl;dr : Oui vous debe et avec OpenPojo c'est trivial.

1. Vous devriez faire de la validation dans vos getters et setters, donc vous devriez les tester. Par exemple, setMom(Person p) ne devraient pas permettre de prendre pour mère une personne plus jeune qu'eux.

2. Même si vous ne faites rien de tout cela aujourd'hui, il y a de fortes chances que vous le fassiez à l'avenir, ce qui constitue une bonne analyse de régression. Si vous voulez permettre aux mères encadrantes de null vous devriez avoir un test pour cela, si quelqu'un le change plus tard, cela renforcera vos hypothèses.

3. Un bug commun est void setFoo( Object foo ){ foo = foo; } où il devrait être void setFoo( Object foo ){ this.foo = foo; } . (Dans le premier cas, le foo dans lequel on écrit est le paramètre no le site foo dans le champ objet ).

4. Si vous renvoyez un tableau ou une collection, vous devez tester si le récupérateur va ou non exécuter le test. copies de sécurité des données passées dans le setter avant de revenir.

5. Sinon, si vous avez les setters/getters les plus basiques, le test unitaire de ceux-ci ajoutera peut-être 10 minutes au maximum par objet, alors quelle est la perte ? Si vous ajoutez un comportement, vous avez déjà un squelette de test et vous obtenez ce test de régression gratuitement. Si vous utilisez Java, vous n'avez aucune excuse puisqu'il existe des tests de régression. OpenPojo . Il existe un ensemble de règles que vous pouvez activer, puis balayer l'ensemble de votre projet avec elles pour vous assurer qu'elles sont appliquées de manière cohérente dans votre code.

De leur exemples :

final Validator pojoValidator = ValidatorBuilder.create()
        .with(
            new NoPublicFieldsRule  (),
            new NoPrimitivesRule    (),
            new GetterMustExistRule (),
            new SetterMustExistRule ()
        )
        .with(
            new DefaultValuesNullTester (),
            new SetterTester            (),
            new GetterTester            ()
        )
        .build();

pojoValidator.validate(  PojoClassFactory.getPojoClasses( "net.initech.app", new FilterPackageInfo() )  );

Answer 4

Bien qu'il existe des raisons justifiées pour les propriétés, une croyance commune en matière de conception orientée objet veut que l'exposition de l'état des membres via les propriétés soit une mauvaise conception. Article de Robert Martin sur le principe de l'ouverture et de la fermeture. poursuit en affirmant que les propriétés encouragent le couplage et limitent donc la possibilité de fermer une classe aux modifications - si vous modifiez la propriété, tous les consommateurs de la classe devront également le faire. Il précise que l'exposition des variables membres n'est pas nécessairement une mauvaise conception, mais simplement un mauvais style. Cependant, si les propriétés sont en lecture seule, il y a moins de risques d'abus et d'effets secondaires.

La meilleure approche que je puisse proposer pour les tests unitaires (et cela peut paraître étrange) est de rendre le plus grand nombre possible de propriétés protégées ou internes. Cela permet d'éviter le couplage tout en décourageant l'écriture de tests stupides pour les getters et setters.

Il existe des raisons évidentes pour lesquelles les propriétés en lecture/écriture doivent être utilisées, comme les propriétés du ViewModel qui sont liées aux champs de saisie, etc.

De manière plus pratique, les tests unitaires devraient conduire la fonctionnalité à travers les méthodes publiques. Si le code que vous testez utilise ces propriétés, vous obtenez une couverture de code gratuite. S'il s'avère que ces propriétés ne sont jamais mises en évidence par le code-coverage, il y a une très forte possibilité que :

1. Il vous manque des tests qui utilisent indirectement les propriétés
2. Les propriétés sont inutilisées

Si vous écrivez des tests pour les getters et setters, vous obtenez une fausse impression de couverture et vous ne serez pas en mesure de déterminer si les propriétés sont réellement utilisées par le comportement fonctionnel.

Answer 5

Si le complexité cyclomatique du getter et/ou du setter est égal à 1 (ce qui est généralement le cas), alors la réponse est non, vous ne devez pas le faire.

Donc, à moins que vous n'ayez un accord de niveau de service qui exige une couverture du code à 100 %, ne vous donnez pas la peine et concentrez-vous sur le test de l'aspect important de votre logiciel.

P.S. N'oubliez pas de différencier les getters et les setters, même dans des langages comme C# où les propriétés peuvent sembler être la même chose. La complexité du setter peut être supérieure à celle du getter, et donc valider un test unitaire.