Je serais aussi défensif que vous devez l'être. Un peu ambigu, je suppose que oui mais je vais essayer de l'expliquer.
Lorsque vous rectifiez une méthode, si cette méthode a des paramètres d'entrée, vous devez décider de ce que vous attendez de ces paramètres. Dans les situations et les emplacements d'une application, cela diffère. Par exemple, si une méthode ou un morceau de code accepte des données provenant d'une entrée utilisateur, vous voudrez couvrir toute la base de code et gérer toute entrée en conséquence, que ce soit via un message d'erreur ou une belle façon d'afficher des données inacceptables.
Si la méthode est une API exposée idem. Vous ne pouvez pas contrôler ce qui arrive, vous devez donc vous attendre à essayer de couvrir tous les aspects et à programmer en conséquence.
Pour les méthodes produites dans le moteur principal de votre projet, vous avez ici une décision à prendre. Dois-je supposer que les données qui arrivent ont été présélectionnées et validées avant leur arrivée ou dois-je effectuer les vérifications nécessaires. Je suppose que cela dépend du niveau conceptuel de la méthode et si c'est un endroit acceptable à vérifier. Donc, les choses que je pourrais considérer sont:
1) Est-ce le seul endroit où j'aurai besoin de faire cette vérification? Cette variable devra-t-elle être vérifiée dans de nombreux endroits différents pour cette condition? Si c'est le cas, puis-je faire le contrôle une fois plus haut dans la chaîne et ensuite assumer la validité par la suite
2) D'autres composants du système devraient-ils fonctionner avec les méthodes et les interfaces que j'écris? Si tel est le cas, vous pouvez contrôler par le biais des instructions d'assertion de débogage, des exceptions de débogage, des commentaires de méthode et de l'architecture générale du système le résultat dont vous avez besoin, ou les données doivent-elles être vérifiées.
3) Quels sont les résultats de l'échec à ce stade du code. Cela fera-t-il échouer tout cela? Toute erreur sera-t-elle détectée ailleurs et cette erreur sera-t-elle au moins détectée.
4) Est-il judicieux de mettre un chèque ici? Parfois, mettre un chèque sur un morceau de données corrompues possibles, bien que contribuer à résoudre le problème à ce stade et non à une erreur, pourrait aider à le couvrir. À ce moment-là, vous pourriez passer des heures à rechercher un problème différent pour découvrir que le problème réel était dû à une vérification valide des données dans la chaîne d'événements en cascade à celui signalé par l'utilisateur / développeur.
En général, je suis un programmeur défensif, mais je crois également qu'avec un TDD approfondi et des tests unitaires appropriés, vous pouvez mettre les contrôles dans le code aux niveaux requis et être sûr qu'il fonctionne comme il le devrait une fois qu'il arrive dans les sections de niveau inférieur. .