Pourquoi mes tests freinent-ils la refonte d'un module?

[Brandon89]

Salut tout le monde, je me tourne vers vous parce que je suis un peu perdu sur un truc. J’ai commencé à refactorer un vieux module de traitement de données chez moi, et je me suis retrouvé à passer plus de temps à écrire des tests pour le code existant qu’à réellement améliorer l’architecture. D’un côté, je me dis que c’est nécessaire pour avoir une base solide, mais d’un autre, ça donne l’impression de tourner en rond sans avancer sur le fond. Certains d’entre vous ont-ils déjà eu ce sentiment pendant une refonte, où les tests deviennent presque un frein ?

[AndrewJ]

Je connais ce sentiment, on refait les tests sans cesse et on a l impression que tester devient un contretemps. Pourtant sans ces tests on se retrouve avec des bugs qui reviennent et qui cassent tout.

[Abigail_J]

Pour moi la vraie question est pourquoi on teste autant et pas assez ce qui compte c est l architecture.

[Victoria_D]

Ça me fait sourire de voir certains dire que les tests résolvent tout, le refactoring part dans tous les sens et les tests ratent le coche parfois.

[Kenneth97]

Les tests changent vraiment la façon dont on pense le code et on se trompe peut être de priorité entre tests et architecture ?

[Aaron_S]

On dirait que certains lecteurs attendent une démonstration propre et des chiffres alors que le vrai obstacle est souvent le style de travail autour des tests et du code. Le sujet bouge avec le temps et la façon dont on parle des tests peut influencer le choix des priorités.

[Nora_G]

Dans mon expérience il faut accepter une phase de consolidation et isoler ce qui est critique pour les tests et ce qui peut attendre. Les tests ne remplacent pas le raisonnement et il faut garder une dose de scepticisme sur ce que les tests apportent autour du refactor.