Je suis actuellement en train de refactoriser une partie d'une grande base de code sans aucun test unitaire. J'ai essayé de refactoriser le code de manière brute, c'est-à-dire en essayant de deviner ce que fait le code et quels changements ne changeraient pas sa signification, mais sans succès: il casse au hasard les fonctionnalités tout autour de la base de code.
Notez que le refactoring comprend le déplacement du code C # hérité vers un style plus fonctionnel (le code hérité n'utilise aucune des fonctionnalités de .NET Framework 3 et versions ultérieures, y compris LINQ), l'ajout de génériques là où le code peut en bénéficier, etc.
Je ne peux pas utiliser de méthodes formelles , étant donné combien coûteraient-elles.
D'un autre côté, je suppose qu'au moins la règle "Tout code hérité refacturé doit être accompagné de tests unitaires" doit être strictement suivie, quel qu'en soit le coût. Le problème est que lorsque je refaçonne une petite partie d'une méthode privée de 500 LOC, l'ajout de tests unitaires semble être une tâche difficile.
Qu'est-ce qui peut m'aider à savoir quels tests unitaires sont pertinents pour un morceau de code donné? Je suppose que l'analyse statique du code serait en quelque sorte utile, mais quels sont les outils et les techniques que je peux utiliser pour:
Savoir exactement quels tests unitaires dois-je créer,
Et / ou savez-vous si le changement que j'ai effectué a affecté le code d'origine d'une manière qu'il s'exécute différemment à partir de maintenant?
formal methods in software development
toute façon, car il est utilisé pour prouver l'exactitude d'un programme en utilisant une logique de prédicat et n'aurait pas d'application pour refactoriser une grande base de code. Méthodes formelles généralement utilisées pour prouver que le code fonctionne correctement dans des domaines tels que les applications médicales. Vous avez raison, il est coûteux de le faire, c'est pourquoi il n'est pas utilisé souvent.