Vous héritez d'un service sans aucun test et vous devez changer sa logique centrale. Comment vous y prenez-vous ?

Figez le comportement actuel avant de le changer. Écrivez des tests de caractérisation à une frontière stable, en fournissant de vraies entrées et en affirmant ce que le code fait aujourd'hui, bugs compris, pour avoir un filet qui détecte le changement. Ensuite refactorez par petites étapes avec ces tests au vert, en extrayant la logique à toucher vers quelque chose de testable. Ce n'est qu'une fois la couture en place que vous changez le comportement, et chaque changement obtient son propre test.

Je ne change pas de la logique que je ne peux pas vérifier, donc l'étape un, c'est un filet. J'écris des tests de caractérisation à la frontière stable la plus haute, en général le handler HTTP ou un point d'entrée de service, et j'affirme ce que le code fait à l'instant présent, y compris des choses que je soupçonne d'être des bugs. Le but n'est pas la justesse, c'est de détecter le changement. Si j'ai accès à la production, je capture quelques centaines de vraies paires requête et réponse, parce que des entrées faites main ratent les cas bizarres et que ce sont les cas bizarres qui cassent. Ensuite je refactore par petites étapes avec les tests au vert tout du long, en tirant la logique que j'ai réellement besoin de toucher vers une fonction que je peux appeler directement. Ce n'est qu'alors que je change le comportement, et chaque changement vient avec un vrai test plus une décision sur le fait de savoir si l'ancien comportement était intentionnel. Sur un service de tarification hérité, j'ai fait exactement ça et le trafic capturé a exposé deux chemins d'arrondi qui se contredisaient, ce que personne ne savait. C'est le genre de chose qu'on trouve avec un filet et qu'on détruit sans.