Tests d'acceptation de tests unitaires?

Question

J'effectue actuellement des tests d'acceptation qui aideront à concevoir un programme que je suis sur le point de réaliser. Tout semble bien, sauf que j'ai réalisé que les tests d'acceptation sont assez complexes, c'est-à-dire, bien qu'ils soient conceptuellement simples, ils nécessitent un peu de code difficile à exécuter. Je vais devoir faire quelques cours d'aide pour mes tests d'acceptation.

Ma question est comment les développer:

1. Faire-parts Tests de mon acceptation-tests (ce qui semble étrange - quelqu'un a fait quelque chose comme ça?)
2. Faire tests unitaires pour ces classes d'aide. Après avoir fait tout le code de ces classes d'aide, je peux passer et commencer à travailler sur les vrais tests unitaires de mon système. En utilisant cette approche, où mettriez-vous les classes auxiliaires? Dans le projet des tests ou dans le vrai projet? Ils n'ont pas nécessairement de dépendances sur les frameworks de tests/moqueurs.
3. Une autre idée?

Answer 1

Si vous considérez le développement de logiciels comme une usine de production automobile, l'acte d'écrire un logiciel est comme le développement d'une nouvelle voiture. Chaque composant est testé séparément car il est nouveau. Cela n'a jamais été fait auparavant. (Si c'est le cas, vous pouvez soit obtenir des gens qui l'ont déjà fait ou l'acheter.)

Votre système de construction, qui construit votre logiciel et qui le teste, est comme le convoyeur - le processus qui débite voiture après voiture après voiture. Les constructeurs automobiles considèrent généralement comment ils vont automatiser la production de nouveaux composants et tester leurs voitures dans le cadre de la création de nouveaux composants, et vous pouvez parier qu'ils testent également les machines qui produisent ces voitures. Donc, oui, le test unitaire de vos tests d'acceptation me semble parfaitement bien, surtout si cela vous aide à aller plus vite et à garder les choses plus faciles à changer.

Answer 2

Il n'y a rien de mal à utiliser un framework de test unitaire (comme JUnit) pour écrire des tests d'acceptation (ou des tests d'intégration). Les gens n'aiment pas les appeler «tests unitaires» pour plusieurs raisons. Pour moi, la raison principale est que les tests d'intégration/acceptation ne se dérouleront pas à chaque fois que l'on vérifie les changements (trop long ou/et pas d'environnement approprié).

Vos classes auxiliaires sont plutôt chose standard qui comprennent "code d'infrastructure de test". Ils n'appartiennent pas ailleurs que le code de test. C'est votre choix pour les tester ou non. Mais sans eux, vos tests ne seront pas réalisables dans les grands systèmes. Donc, votre choix est # 2 ou aucun test de tests du tout. Il n'y a rien de mal à refactoriser le code d'infrastructure pour le rendre plus transparent et simple.

Answer 3

Votre option 2 est la façon dont je le ferais: écrire des classes d'aide test-first - il semble que vous sachiez ce qu'ils devraient faire.

Les tests sont des tests, et bien que les classes auxiliaires ne soient pas strictement des tests, ils ne seront pas référencés par votre code principal, seulement les tests, donc ils appartiennent aux tests. Peut-être qu'ils pourraient être dans un paquet séparé/espace de noms des tests réguliers.

Answer 4

Un ami est très enthousiaste à l'idée que les tests d'acceptation vous disent si votre code est cassé, tandis que les tests unitaires vous disent où est cassé; ce sont des éléments d'information complémentaires et précieux. Les tests d'acceptation vous permettent de savoir quand vous avez terminé. Mais pour y arriver, vous avez besoin de toutes les pièces en cours de route; vous avez besoin d'eux pour travailler, et c'est ce que les tests unitaires sont excellents. Test effectué - d'abord, il vous permettra également de mieux concevoir (pas seulement le code qui fonctionne). Une bonne approche consiste à écrire un test d'acceptation de grande image, et à se dire: «quand cela passera, j'en aurai fini». Ensuite, travaillez pour le faire passer, en travaillant TDD: écrivez un petit test unitaire pour la prochaine petite fonctionnalité dont vous avez besoin pour faire passer l'AT; écris le code pour le faire passer; refactor; répéter. À mesure que vous progressez, exécutez l'AT de temps en temps; vous trouverez probablement échouer plus tard et plus tard dans le test. Et, comme mentionné ci-dessus, quand il passe, vous avez terminé.

Je ne pense pas que le test unitaire du test d'acceptation lui-même ait beaucoup de sens. Mais l'unité testant ses classes auxiliaires - en effet, en les écrivant test-first - est un très bon moyen d'aller. Vous trouverez probablement des méthodes que vous écrivez "juste pour le test" qui se fraient un chemin dans le code de production - et même si vous ne le faites pas, vous voulez toujours savoir que le code utilisé par vos AT fonctionne correctement.Si votre AT est assez simple, le vieil adage de "le test teste le code, et le code teste le test" est probablement suffisant - quand vous avez un test qui échoue, c'est soit parce que le code est faux ou parce que le test est faux, et il devrait être assez facile de comprendre lequel. Mais quand le test est compliqué, il est bon que ses sous-bases soient également testées.