Comment tester un code qui ne devrait jamais être exécuté?

Question

La méthode suivante ne doit être appelée que s'il a été vérifié qu'il y a des chiffres invalides (en appelant une autre méthode). Comment puis-je tester le throw-line dans l'extrait de code suivant? Je sais que l'one-way pourrait être de fusionner ensemble le VerifyThereAreInvalidiDigits et cette méthode. Je cherche d'autres idées. Je voudrais également ne pas écrire un test unitaire qui exerce un code qui ne devrait jamais être exécuté.

Answer 1

Si le « jeter » la déclaration en question est vraiment injoignable dans tout scénario possible, alors il devrait être supprimé et remplacé par:

Debug.Fail("This should be unreachable; please find and fix the bug that caused this to be reached."); 

Si le code est accessible alors écrire un test d'unité teste ce scénario. Les scénarios de rapport d'erreurs pour les méthodes accessibles au public sont des scénarios parfaitement valides. Vous devez gérer toutes les entrées correctement, même les mauvaises entrées. Si la bonne chose à faire est de lancer une exception, alors testez que vous lancez une exception. MISE À JOUR: selon les commentaires, il est en fait impossible de toucher l'erreur et donc le code est inaccessible. Mais maintenant le Debug.Fail n'est pas accessible non plus, et il ne compile pas parce que le compilateur note qu'une méthode qui retourne une valeur a un point d'extrémité atteignable.

Le premier problème ne devrait pas réellement être un problème; L'outil de couverture de code doit sûrement être configurable pour ignorer le code de débogage inaccessible. Mais à la fois problème peut être résolu par la réécriture de la boucle:

public int FirstInvalidDigitPosition 
{ 
    get 
    { 
     int index = 0; 
     while(true) 
     { 
      Debug.Assert(index < this.positions.Length, "Attempt to get invalid digit position but there are no invalid digits!"); 
      if (!this.positions[index].Valid) return index; 
      index++; 
     } 
    } 
} 

Une autre approche serait de réorganiser le code de sorte que vous n'avez pas le problème en premier lieu:

public int? FirstInvalidDigitPosition { 
    get { 
     for (int index = 0; index < this.positions.Count; ++index) { 
      if (!this.positions[index].Valid) return index; 
     } 
     return null; 
    } 
} 

et maintenant vous n'avez pas besoin de restreindre les appelants pour appeler AreThereInvalidDigits en premier; Il est juste légal d'appeler cette méthode à tout moment. Cela semble être la chose la plus sûre à faire. Les méthodes qui explosent lorsque vous ne faites pas de vérification coûteuse pour vérifier qu'elles sont sûres d'appeler sont des méthodes fragiles et dangereuses.

Answer 2

Je ne comprends pas pourquoi vous ne voudriez pas écrire un test unitaire qui utilise un "code qui ne devrait pas arriver".

Si cela "ne devrait pas arriver", alors pourquoi écrivez-vous le code? Parce que vous pensez que cela pourrait arriver bien sûr - peut-être qu'une erreur dans un futur refactoring va casser votre autre validation et que ce code sera exécuté.

Si vous pensez que cela vaut la peine d'écrire le code, il vaut la peine de le tester.

Answer 3

Une partie de l'objectif de l'essai est de tester les deux choses qui devrait arriver et les choses qui peuvent arriver.

Si vous avez du code qui devrait jamais exécuter, mais pourrait dans les bonnes conditions (ou mal), vous pouvez vérifier que l'exception se produit dans les bonnes conditions (dans Unit Test Framework de MS) en décorant votre test méthode avec:

[ExpectedException(typeof(InvalidOperationException))] 

Answer 4

Il est parfois nécessaire d'écrire des petits morceaux de code qui ne peut pas exécuter, juste pour apaiser un compilateur (par exemple, si une fonction qui jettent toujours une exception, quitte l'application, etc. est appelé à partir une fonction qui est supposée renvoyer une valeur, le compilateur peut insister pour que l'appelant inclue un "return 0", "Return Nothing" ", etc. déclaration qui ne peut jamais être exécutée. Je ne pense pas que l'on devrait être obligé de tester un tel "code", car il peut être impossible de le faire exécuter sans sérieusement casser d'autres parties du système.

Une question plus intéressante vient avec le code que le processeur ne devrait jamais être capable d'exécuter dans des circonstances normales, mais qui existe pour minimiser les dommages causés par des circonstances anormales. Par exemple, certaines applications critiques pour la sécurité que j'ai début écrit avec quelque chose comme code (application réelle est le code de la machine, étant donné ci-dessous est pseudo-code)

 
    register = 0 
    test register for zero 
    if non-zero goto dead 
    register = register - 1 
    test register for zero 
    if non-zero goto okay1 
dead: 
    shut everything down 
    goto dead 
okay1: 
    register = register + 1 
    if non-zero goto dead 

Je ne sais pas exactement comment on pourrait s'y prendre pour les tests ce code dans le cas d'échec. Le but du code est de s'assurer que si le registre a subi des dommages électrostatiques ou autres, ou qu'il ne fonctionne pas, le système s'arrêtera en toute sécurité. En l'absence de matériel très sophistiqué, je ne sais pas comment tester un tel code.