Est-ce une odeur de code d'utiliser un fichier généré, comme une feuille de calcul ou un fichier XML, comme source de comparaison dans les tests unitaires?
Disons que nous avons dû écrire beaucoup de classes qui produisent divers fichiers XML pour un traitement ultérieur. Les tests unitaires seraient un grand nombre d'assertions répétitives que foo.getExpectedValue () = expectedValue . Au lieu de faire cela, le développeur choisit d'utiliser le code qu'il est censé tester pour générer le XML, puis le copier dans test / ressources pour que tous les tests futurs se chargent en mémoire en tant qu'objet et pour exécuter leurs assertions. Est-ce une odeur de code?
3 Réponses :
Oui, je ne ferais pas ça. Cela brise les principes d'un bon test. Principalement, un bon test de test devrait être;
Peut-être pourriez-vous prendre du recul et voir si vous avez besoin d'un test unitaire de chaque XML généré. Si ces générations de fichiers suivent le même chemin d'exécution de code avec (aucune différence logique), je n'écrirais pas de test unitaire pour chaque cas. Si cette génération XML est liée aux opérations commerciales, j'envisagerais de faire des tests d'acceptation.
Il y a deux pratiques dans ce que vous décrivez et qui sont classées comme odeurs de test.
Tout d'abord, vous écrivez que les classes à tester sont utilisées pour créer les fichiers XML qui seront ensuite utilisés pour juger de l'exactitude. De cette façon, vous pouvez savoir s'il y a des changements dans les classes, mais vous ne pouvez pas savoir si les résultats étaient corrects en premier lieu.
Pour éviter tout malentendu: l'odeur n'est pas que les fichiers générés sont utilisés, mais que les fichiers sont générés avec le code en cours de test. La seule façon dont une telle approche pourrait avoir un sens serait que les résultats de l’exécution initiale fassent l’objet d’un examen approfondi. Mais, ces révisions devraient être répétées à nouveau chaque fois que les fichiers sont régénérés plus tard.
Deuxièmement, l'utilisation de fichiers XML complets à des fins de comparaison (générés ou non) est un autre petit test. La raison en est que ces tests ne sont pas très ciblés. Toute modification de la génération XML entraînera un échec du test. Cela peut sembler une bonne chose, mais cela s'applique même à toutes sortes de modifications prévues, par exemple aux modifications de l'indentation. Ainsi, vous n'avez que des tests qui vous indiquent "quelque chose a changé", mais pas "quelque chose a échoué".
Pour avoir des tests qui vous indiquent "quelque chose a échoué", vous avez besoin de tests plus spécifiques. Par exemple, des tests qui ne regardent qu'une certaine partie du XML généré. Certains tests porteraient sur la structure XML, d'autres sur le contenu des données. Vous pouvez même faire des tests pour vérifier l'indentation. Mais comment? Vous pouvez, par exemple, utiliser des expressions régulières pour voir si une partie intéressante d'une chaîne XML générée ressemble à ce que vous attendiez.
Une fois que vous avez des tests plus ciblés, le reste des résultats en cas de modifications prévues de votre code sera différent: lorsque vos modifications sont réussies, seuls quelques cas de test échoueront, et ce seront ceux qui auront testé par rapport à la partie du comportement que vous avez intentionnellement modifiée. Tous les autres tests fonctionneront toujours correctement et vous montreront que votre modification n'a pas interrompu quelque chose de manière inattendue. Si en revanche votre modification était incorrecte, alors des tests plus / autres que ceux attendus vous montreront que le changement a eu des effets inattendus.
Si les fichiers sont petits , vous pouvez utiliser un lecteur et un écrivain de chaîne. En général, on est censé éviter de faire des E / S dans les tests unitaires . Cependant, je ne vois rien de mal à utiliser des fichiers dans certains tests non unitaires.