Test unitaire des méthodes vides ?

Question

Quelle est la meilleure façon de tester unitairement une méthode qui ne renvoie rien ? Plus précisément en C#.

Ce que j'essaie vraiment de tester, c'est une méthode qui prend un fichier journal et l'analyse à la recherche de chaînes de caractères spécifiques. Ces chaînes sont ensuite insérées dans une base de données. Rien qui n'ait été fait auparavant, mais étant TRÈS novice en matière de TDD, je me demande s'il est possible de tester cette méthode ou si c'est quelque chose qui n'est pas vraiment testé.

Answer 1

Si une méthode ne renvoie rien, il s'agit de l'un des cas suivants

• impératif - Soit vous demandez à l'objet de faire quelque chose à lui-même, par exemple changer d'état (sans attendre de confirmation, il est supposé que cela sera fait).
• information - simplement notifier à quelqu'un que quelque chose s'est produit (sans attendre d'action ou de réponse) respectivement.

Méthodes impératives - vous pouvez vérifier si la tâche a été réellement effectuée. Vérifier si le changement d'état a réellement eu lieu. par exemple

void DeductFromBalance( dAmount ) 

peut être testé en vérifiant si le solde après ce message est bien inférieur à la valeur initiale par dAmount

Méthodes d'information - sont rares en tant que membre de l'interface publique de l'objet ... donc pas normalement unit-tested. Cependant, si vous devez le faire, vous pouvez vérifier si la manipulation à faire sur une notification a lieu. par ex.

void OnAccountDebit( dAmount )  // emails account holder with info

peut être testé en vérifiant si l'e-mail est envoyé

Publiez plus de détails sur votre méthode actuelle et les gens seront en mesure de mieux répondre.
Mise à jour : Votre méthode fait 2 choses. En fait, je la diviserais en deux méthodes qui peuvent maintenant être testées indépendamment.

string[] ExamineLogFileForX( string sFileName );
void InsertStringsIntoDatabase( string[] );

String[] peut être facilement vérifié en fournissant à la première méthode un fichier factice et les chaînes attendues. La deuxième méthode est un peu plus délicate vous pouvez soit utiliser un Mock (google ou recherche stackoverflow sur les frameworks de mocking) pour imiter la base de données, soit utiliser la base de données réelle et vérifier si les chaînes ont été insérées au bon endroit. Vérifiez ce fil pour quelques bons livres... Je recommanderais Pragmatic Unit Testing si vous êtes dans le pétrin.
Dans le code, il serait utilisé comme suit

InsertStringsIntoDatabase( ExamineLogFileForX( "c:\OMG.log" ) );

Answer 2

Testez ses effets secondaires. Cela comprend :

• Lance-t-il des exceptions ? (Si elle devrait, vérifiez qu'elle le fait. S'il ne devrait pas, essayez quelques cas de coin qui pourraient le faire si vous n'êtes pas prudent - les arguments nuls étant la chose la plus évidente).
• Joue-t-il en harmonie avec ses paramètres ? (S'ils sont mutables, les fait-elle muter alors qu'elle ne devrait pas le faire et vice versa).
• A-t-elle le bon effet sur l'état de l'objet/type sur lequel vous l'appelez ?

Bien sûr, il y a une limite à la façon dont beaucoup que vous pouvez tester. Vous ne pouvez généralement pas tester avec toutes les entrées possibles, par exemple. Testez de manière pragmatique - suffisamment pour vous donner confiance dans le fait que votre code est conçu de manière appropriée et implémenté correctement, et suffisamment pour servir de documentation supplémentaire pour ce qu'un appelant pourrait attendre.

Answer 3

Comme toujours : testez ce que la méthode est censée faire !

Doit-il changer l'état global (uuh, odeur de code !) quelque part ?

Doit-il faire appel à une interface ?

Doit-il lever une exception lorsqu'il est appelé avec les mauvais paramètres ?

Ne devrait-il pas lever une exception lorsqu'il est appelé avec les bons paramètres ?

Devrait-elle... ?

Answer 4

Il aura un certain effet sur un objet.... requête pour le résultat de l'effet. Si l'effet n'est pas visible, cela ne vaut pas la peine de faire des tests unitaires !

Answer 5

On peut supposer que la méthode fait quelque chose, et ne se contente pas de revenir ?

En supposant que c'est le cas, alors :

1. S'il modifie l'état de son objet propriétaire, alors vous devez tester que l'état a changé correctement.
2. S'il prend un objet en paramètre et modifie cet objet, vous devez tester que l'objet est correctement modifié.
3. S'il lève des exceptions dans certains cas, vérifiez que ces exceptions sont correctement levées.
4. Si son comportement varie en fonction de l'état de son propre objet ou d'un autre objet, il faut prédéfinir l'état et tester que la méthode a le bon Ià travers l'une des trois méthodes de test ci-dessus).

Si vous nous indiquiez ce que fait la méthode, je pourrais être plus précis.