En effet, pour pouvoir vérfier le bon fonctionnement d'un setter, le développeur doit faire appel au getter correspondant.

A l'inverse, pour pouvoir vérfier le bon fonctionnement d'un getter, le développeur doit faire appel au setter correspondant.

Bref, c'est l'histoire de la poule et de l'oeuf, et c'est l'un de ses problèmes qui n'ont pas de solution.

Un shadock dirait donc avec raison :

S'il n'y a pas de solution, c'est qu'il n'y a pas de problème !

En effet, les tests existents pour valider un comportement, et en conséquence, leur ordre et la façon dont ils sont organisés importe peu.

En théorie, il est tout à fait possible de valider le comportement de l'ensemble des méthodes publiques d'une classe dans une et une seule méthode de test.

Cependant, les tests seraient alors difficile à maintenir et à faire évoluer, comme tout bon code spaghetti.

C'est pourquoi dans la pratique, les tests sont souvent structurés en attribuant une méthode de test à une méthode publique de la classe.

Cependant, il ne s'agit que d'une convention destinée à faciliter la vie des développeurs, et donc d'une régle qui peut et doit être transgréssée lorsqu'il n'y a pas moyen de faire autrement, et c'est justement le cas avec les getter et les setter.

Par ailleurs, il existe d'autre convention pour l'écriture des tests.

Chez No Parking, les tests sont structurés en fonction des différents cas de figure possibles.

En conséquence, une même méthode publique de classe peut donc être testée dans plusieurs méthodes de test.

Il n'est donc absolument pas obligatoire d'avoir une méthode de test pour chaque méthode de la classe à tester.

Evidement, si ce n'est pas le cas, il est plus difficile de définir le coupable lorsque la méthode de test ne passe plus.

Est-ce le setter ? Est-ce le getter ? Les deux ? Non, c'est le colonel Moutarde avec le chandelier dans la bibliothèque !

Cependant, n'est ce pas là le rôle du développeur de mener l'enquête pour trouver le fautif ?

Il ne faut pas trop en demander aux tests unitaires, ils ne sont qu'un outil de diagnostic,

Tout comme le stétoscope du médecin qui lui permet de vous dire que vous avez un problème cardiaque, les tests permettent au développeur de savoir que son code ne fonctionne pas comme il le devrait.

Et tout comme le stétoscope du médecin ne lui permet pas vous dire le traitement approprié, les tests ne permettent pas au développeur de savoir ce qu'il doit faire pour résoudre le problème.

C'est à l'expert, c'est à dire le médecin ou le développeur, aidé des informations qui sont fournies par ses outils et par ses capacités d'analyse, ses compétences et son expérience, de faire le diagnostic et d'appliquer le traitement correspondant.

Les tests ne remplacent pas le développeur, et encore heureux car dans le cas contraire, ces derniers seraient au chomage.

Il est donc inutile de s'interroger sur l'ordre dans lequel les tests doivent être effectués ou organisés.

Ce n'est d'ailleurs pas pour rien que les outils d'automatisation des tests unitaires proposent bien souvent une option permettant de les effectuer dans un ordre aléatoire, ou bien d'effectuer chaque méthode dans un processus séparé afin d'avoir un environnement d'éxécution propre et vierge à chaque fois.