J'écris un analyseur pour la sortie d'une application héritée et, étant donné qu'il n'y a pas de spécifications sur la syntaxe de fichier, j'ai autant d'échantillons de ces fichiers que possible.
Maintenant, j'écris les tests de l'unité avant de mettre en œuvre l'analyseur (car il n'y a pas d'autre moyen sain de le faire) mais je ne sais pas si je devrais:
Je suis enclin à utiliser la deuxième alternative parce que je ne testerais que ce que je dois, sans toutes les données "du monde réel" incluses dans les fichiers réels, mais je crains que je puisse oublier de tester une possibilité ou un autre.
Que pensez-vous?
5 Réponses :
Ma suggestion est de faire les deux. Écrivez un ensemble d'essais d'intégration qui parcourent tous les fichiers que vous disposez aux sorties attendues, puis test unitaire avec vos entrées attendues pour isoler la logique d'analyse.
Je recommanderais d'écrire d'abord les tests d'intégration afin que vous écriviez votre analyseur à l'extérieur, il peut être déprécié de voir un tas de tests échoués, mais cela vous aidera à isoler vos cas de bord plus tôt.
BTW, je pense que c'est une excellente question. J'ai récemment rencontré quelque chose qu'un problème similaire transformait de grandes aliments XML d'un système en amont en format propriétaire. Ma solution consistait à écrire un ensemble d'essais d'intégration Black Box pour les aliments complets de tests tels que les comptes d'enregistrement et autres métriques de réussite de haut niveau, puis décomposer les entrées dans des morceaux plus petits et plus petits jusqu'à ce que je puisse tester toutes les permutations des données. Ce n'est qu'alors que j'ai eu une bonne compréhension de la construction de l'analyseur.
N'oubliez pas de structurer le test de telle sorte que vous puissiez ajouter des possibilités supplémentaires (c'est-à-dire des tests de régression) comme ils sont connus.
Utilisation de la deuxième solution que vous offre vous permettra de contrôler ce qui est attendu et ce qui est retourné, ce qui est idéal pour les tests unitaires. Lors de la création de tests automatisés, il est préférable d'éviter l'interaction manuelle aussi souvent que possible - la numérisation visuelle des résultats est l'une de ces pratiques à éviter lorsque cela est possible (en supposant que c'est ce que vous vouliez dire par "comparer").
Je ne voulais pas vérifier manuellement la sortie, je voulais dire tester un fichier volumineux avec certaines données non pertinentes, mais un fichier réel, au lieu de tester les cas que j'ai présentés comme j'ai appris ce que l'on a appris à l'attente de mon analyseur.
Vous devez faire attention à utiliser des données de production dans des scénarios de test. Cela pourrait être un désastre si tous vos utilisateurs ont reçu un courrier électronique à partir d'un environnement de test, par exemple. Son également probablement contraire à l'éthique dans certains scénarios pour les développeurs d'avoir accès à des données de produit, même s'il n'y a aucun moyen pour les utilisateurs de le savoir. Pensez aux types de scénarios médicaux médicaux, banques et collèges.
Ma réponse est que vous devez utiliser des données proches des données Prod. Si vous souhaitez utiliser les données de produit réelles, vous devez le frotter pour les scénarios ci-dessus.
Les données de production peuvent être un bon point de départ (en supposant que ce n'est pas une information sensible), car il y a une bonne chance que vous ne puissiez pas penser à toutes les permutations possibles vous-même. Cependant, une fois que vous avez un bon ensemble de données de travail, enregistrez-le quelque part statique, comme un fichier. Ensuite, demandez aux tests de l'obtenir à partir de là au lieu de dynamiquement de l'environnement de production. De cette façon, vous pouvez exécuter les tests avec un ensemble d'entrées connu à chaque fois.
L'alternative, obtenir des données de production à la volée pour les entrées de test, est semée de problèmes. Les modifications apportées aux données pourraient faire passer un test une fois, mais échouez à la suivante car les entrées ont changé.
Je pense que ces cas de bord - parfois passent, parfois échouent - sont exactement l'avantage de tester des données réelles. N'attendez pas que la libération pour trouver ces bugs.