J'essaie de devenir plus familier avec les approches axées sur les tests. Un inconvénient pour moi est qu'une partie importante de mon code est générée dans le contexte de la déclaration (documents PDF, des images de graphique). Il y a toujours un concepteur complexe impliqué et il n'y a pas de test facile de l'exactitude. Aucune chance de tester juste des fragments!
Connaissez-vous les pratiques TDD pour cette situation?
7 Réponses :
Vous pouvez essayer d'utiliser un service Web pour votre source de données de rapport et testez cela, mais vous n'allez pas avoir des tests d'unités pour le rendu. C'est exactement le même problème que vous avez lorsque vous testez des vues. Bien sûr, vous pouvez utiliser un cadre de test Web tel que sélénium, mais vous ne pratiquerez probablement pas vrai TDD. Vous créerez des tests après la fin de votre code.
En bref, utilisez le bon sens. Il n'a probablement pas de sens d'essayer de tester le rendu d'un rapport. Vous pouvez avoir des cas de test manuels qu'un testeur devra passer à la main ou simplement vérifier les rapports vous-même.
Vous voudrez peut-être aussi consulter " Quelle quantité de test d'unité Avez-vous besoin? - Le testtivus répond "
La question que je me pose dans ces situations est "< Comment puis-je savoir que je l'ai bien compris "?
J'ai écrit beaucoup de code dans ma carrière et presque tout cela n'a pas fonctionné la première fois. Presque chaque fois que je suis retourné et j'ai changé de code pour un refactoring, un changement de fonctionnalité, une performance ou une correction de bugs, je la brisais à nouveau. TDD me protège de moi-même (Dieu merci!).
Dans le cas du code généré, je ne me sens pas obligé de tester le code. C'est-à-dire que je fais confiance au générateur de code. Cependant, je veux tester mes les entrées aux générateurs de code. Comment faire cela dépend de la situation, mais l'approche générale est de me demander comment je pourrais vous tromper, puis de déterminer comment vérifier que je l'ai bien compris.
J'écris peut-être un test automatisé. Peut-être que j'inspecte quelque chose manuellement, mais c'est assez risqué. Peut-être autre chose. Cela dépend de la situation.
Certaines applications ou cadres sont juste héritablement test-test-hostile et il n'y a vraiment pas beaucoup que vous puissiez faire à ce sujet.
Je préfère éviter de tels cadres tout à fait, mais si elle est absolument forcée de traiter de tels problèmes, il peut être utile d'extraire toute la logique dans une bibliothèque testable, laissant uniquement du code déclaratif derrière dans le cadre.
Pour mettre un tour légèrement différent sur les réponses de Mark Seepann et Jay Bazuzi:
Votre problème est que le front-end déclarant produit un format de données dont la sortie que vous ne pouvez pas inspecter facilement dans la partie "Vérifier" de vos tests.
La voie à traiter avec ce type de problème est de:
Vous avez des tests d'intégration de très haut niveau qui vérifient superficiellement que votre code arrière est correctement adapté correctement dans votre code frontal. J'appelle habituellement ces tests "Tests de fumée", comme dans "si j'allume le pouvoir et que ça fume, c'est mauvais".
Trouvez un moyen différent de tester votre code de déclaration de back-end. Testez une structure de données de sortie intermédiaire ou implémentez une autre sortie frontale de sortie plus conviviale, HTML, en clairtext, peu importe.
Ceci semblable au problème courant des applications Web de test: Il n'est pas possible de tester automatiquement que "la page a l'air correcte". Mais il suffit de tester que les mots et les chiffres dans les données de page sont corrects (à l'aide d'une surch de navigateur programmatique comme mécanisée et un grattoir de page) et ont quelques tests fonctionnels superficiels (avec sélénium ou moulin à vent) si la page est dépendante de manière critique. sur javascript.
C'était ma première idée de combiner vos "tests de fumée" avec un deuxième test de test contre une base de données avec des résultats de référence. Phase 1: Il n'y a pas d'entrée dans la base de données de référence: test initial; Stockage des résultats, (manuellement) Validation de la phase 2: Retest contre la base de données de référence.
Vous pouvez utiliser le développement d'un test d'acceptation pour remplacer les tests de l'unité et avoir des rapports validés pour des données bien connues utilisées comme références.
Cependant, ce type de test ne donne pas de diagnostic à grain fin en tant que tests unitaires, ils ne fournissent généralement qu'un résultat de passe / échec et, si les rapports changent souvent, les références doivent être régénérées et ré-validées comme bien.
envisager d'extraire le texte du fichier PDF et de le vérifier. Cela ne vous donnera cependant pas de formatage, cependant. Certains programmes d'extraction PDF peuvent extraire les images si les graphiques sont dans le PDF.
C'est considérable. Mais je pense que le code de déconstruire et de valider les PDF de cette manière a la même complexité que la génération de rapport d'origine. Et qui teste les routines de test?
Face à cette situation, j'essaie deux approches.
L'approche principale d'or. Générez le rapport une fois, vérifiez-le vous-même, puis enregistrez-le comme le «maître Golden». Écrivez un test automatisé pour comparer sa sortie avec le maître Golden et échouer quand ils diffèrent.
automate les tests pour les données, mais vérifiez le format manuellement. J'attache des chèques pour le module qui génère les données de rapport, mais de vérifier le format du rapport, je génère un rapport avec des valeurs codées et vérifiez le rapport à la main.
Je vous encourage fortement pas pour générer le rapport complet juste pour vérifier l'exactitude des données sur le rapport. Lorsque vous souhaitez vérifier le rapport (pas les données), générez le rapport; Lorsque vous souhaitez vérifier les données (pas le format), alors générer uniquement les données.