Les exceptions d'argument doivent faire l'objet d'un test d'unité?

Question

Je sais que cette question est assez similaire à d'autres qui ont déjà été postées mais j'aimerais discuter de ce sujet de manière appropriée.

Pensez-vous que l'exception «évidente» devrait être testée à l'unité? Par exception évidente, j'entends par exemple des exceptions dues à des arguments nuls ou à des chaînes vides ou des nombres négatifs dans des situations où la logique métier de notre unité nous rend évident que ces exceptions seront toujours jetées au début de notre méthode (s) avant toute autre opération. En d'autres termes, je parle des exceptions qui devraient être levées après la violation de la partie la plus simple d'un contrat de classe.

Nous vous remercions de votre opinion.

Answer 1

J'inclue habituellement ces tests. C'est vraiment un bon endroit pour commencer le développement, car si vous utilisez TDD vous pouvez avoir le test le plus simple possible pour écrire le code de production, et si vous n'utilisez pas TDD, vous avez un bon test de passage :)

Answer 2

Absolument. Vous les appelez «évidents», mais il n'y a rien d'évident à se rappeler de vérifier les pré-conditions. En fait, la plupart du code que j'ai vu dans ma carrière ne prend pas cette mesure évidente pour empêcher le chaos plus tard.

Alors que vous voyez beaucoup dans le code de la bibliothèque qui est écrit pour la consommation publique, la réutilisation, etc., n'oubliez pas de mettre de telles vérifications dans votre propre code semble souvent glisser par la plupart des développeurs. Dans un environnement piloté par les tests, l'exécution de tests pour de telles conditions force les développeurs à valider correctement les paramètres d'entrée sur leurs méthodes publiques. Et soyons justes ... toute chance d'écrire un autre test et de voir la barre verte, je suis content. :)

Answer 3

Oui, vous devriez tester même la logique la plus simple de vos getters et setters. Si ce code change pendant le refactoring, vous voulez que l'unité teste le filet de sécurité pour s'assurer qu'aucune erreur n'est commise. Exécuter les tests est un moyen très rapide de trouver ces erreurs dès qu'elles sont faites.

La seule fois où je ne teste pas les getters et les setters, c'est s'ils font seulement une simple affectation ou une valeur retournée.

Answer 4

je toujours aussi écrire un test pour ces « simples, évidentes » choses principalement parce que

• Un test selon ces situations « évidentes » est généralement écrit très rapidement et donc je suis presque plus rapide dans rapidement écrire plutôt que de penser le fait sur l'opportunité de mettre un test ou non
• un cas de test simple est mieux que aucun cas de test
• test pour les futurs changements. Avoir un test fait en sorte que tous les autres développeurs de mon équipe ne briseront pas mon code pendant le refactoring/correction de bugs, etc ...