Extraction de classe lors de TDD. Comment tester la nouvelle classe extraite?

Question

J'avais donc quelques méthodes dans ma classe principale qui utilisaient une matrice pour activer ou désactiver les pixels. J'ai tous mes tests courants en cours et ainsi, et j'ai décidé qu'il est déjà temps de sortir une partie de cette logique liée à la matrice et ainsi de créer une classe Matrix. Ma question est, en plus des tests que j'ai actuellement pour ma classe SUT (je suis juste au début, donc je n'ai actuellement qu'un cours, le principal du SUT), devrais-je créer des tests unitaires pour cela? Si oui, comment faites-vous? Je veux dire, est-ce que je laisse tout mon code tel qu'il est en ce moment créer des tests unitaires un par un en faisant une première approche jusqu'à ce que je vois tout ce que je veux faire fonctionnellement et que je refaçonne mon code? Je viens de créer directement la classe Matrix et de m'assurer que les anciens tests sont toujours en cours et que tout va bien?

Merci

Answer 1

Fondamentalement ce dernier. Il n'est pas nécessaire de tester une classe juste parce qu'elle est définie comme une classe distincte. Si vous effectuez un refactoring sans ajouter de fonctionnalité ou changer de comportement, la seule raison d'ajouter des tests est si vous manquez de confiance dans une certaine partie du code. Sinon, le code est déjà testé et le fait qu'il soit testé via une autre classe ne devrait pas avoir d'importance. Cela étant dit, il y a des moments où la structure du code a tellement changé que pour des raisons organisationnelles, vous voulez déplacer le test, ainsi vous pouvez dire d'où provient ce code. Mais c'est une question différente de dire que "c'est une unité indépendante, donc elle doit avoir des tests indépendants".

Answer 2

Pour ce genre de refactoring, le compilateur devrait vous guider. Prenez tout ce que vous voulez dans une classe séparée et compilez. Il vous dira où vous devez utiliser la nouvelle classe dans le code de production et les tests. Refactoriser tout jusqu'à ce qu'il compile et reteste.

La bonne façon de procéder est de déplacer les méthodes/propriétés une à une, cela dépend de votre confort.

EDIT Vous avez seulement besoin de créer suffisamment de tests pour couvrir votre code. Pour des raisons d'organisation, vous devez déplacer les tests de la classe de test principale dans une classe distincte, mais c'est à peu près tout. Si le processus de refactoring nécessite que vous écrivez plus de code (par exemple, une méthode qui crée une instance de la nouvelle classe), vous devez également écrire des tests pour cela.

Dites que vous commencez avec une classe et une classe de test:

OneBigClass 
-Method1 
-Method2 
-Method3 

OneBigClassTest 
-Method1ShouldDoSomething 
-Method2ShouldDoSomething 
-Method3ShouldDoSomething 

Après refactoring c'est ce que vos classes devraient ressembler à:

OneBigClass 
-Method1 
-Method2 

SmallerClass 
-Method3 

OneBigClassTest 
-Method1ShouldDoSomething 
-Method2ShouldDoSomething 

SmallerClassTest 
-Method3ShouldDoSomething 

Answer 3

Un indice relativement commun qu'il est temps de germer une classe est que vous avez des méthodes privées que vous voulez tester. Dans cette situation, laissez les tests conduire réellement le refactoring. Ecrivez le test de la méthode (actuellement privée) dans la classe (non encore écrite); donnez une instance de la nouvelle classe à la classe existante et déplacez la méthode privée dans la nouvelle classe, la rendant publique au fur et à mesure.