J'aimerais savoir de ceux qui documentent l'unité teste comment ils le document. Je comprends que la plupart des adeptes de TDD réclament "le code parle" et donc la documentation du test n'est pas très importante car le code devrait être auto-descriptif. Assez juste, mais j'aimerais savoir Mon expérience en tant que développeur me dit que la compréhension de l'ancien code (cela inclut des tests d'unités) est difficile.
alors qu'est-ce qui est important dans une documentation de test? Quand le nom de la méthode de test n'est pas suffisamment descriptif de manière à ce que la documentation soit justifiée?
6 Réponses :
dans le code de test lui-même:
avec niveau de la méthode Commentaires Expliquer
ce que le test est testant / couvrant.
Au niveau de la classe, un commentaire indiquant la classe actuelle testée (qui pourrait réellement être déduite du nom de la classe de test, de sorte que c'est moins important que les commentaires au niveau de la méthode).
Lorsque vous écrivez vos tests, il est identique à celui lorsque vous écrivez votre code, tout est en cristal pour vous. Cela rend difficile d'envisager ce que vous devriez écrire pour rendre le code plus clair.
Notez que ce ne signifie pas que je n'écris jamais de commentaires . Il y a toujours beaucoup de situations lorsque je sais juste que je vais avoir du mal à déterminer ce qu'un morceau de code particulier fait.
Je commence habituellement avec le point 1 dans ces situations ...
Commentez des tests ou des scénarios complexes si nécessaire mais D'autre part, j'essaie de faire parler de mes tests. En d'autres termes: p> public void PersonShouldSayHello()
Comme je l'ai déjà dit, cela fait pas le document de test lui-même, car vous aurez besoin d'outils hautement spécialisés pour obtenir la documentation du code, et même alors c'est toujours seul code . Je suis totalement avec vous que vous devriez toujours écrire du code qui dit ce qu'il fait, mais cela n'aide toujours pas à comprendre ce qui se passe sans lire le code . Vous ne pouvez pas donner à un client ce code comme une documentation sur ce qui a été testé. Bien sûr, si vous ne vous souciez pas si un client est capable de savoir ce que vous testez, vous devez toujours creuser le code si vous (ou votre patron) veut savoir ce qui est testé.
Je ne peux pas dire que je suis d'accord. Je préfère regarder des tests sur la documentation. En ce qui concerne le patron et les clients, ils ne devraient pas se soucier de ce qui a été testé au niveau de l'unité. Tests fonctionnels cependant, oui. En ce qui concerne les nouveaux développeurs, en regardant des tests unitaires fait partie intégrante du travail IMO.
À la demande de Thorsten79, je vais élaborer mes commentaires comme une réponse. Mon commentaire original était:
"Le code parle" est malheureusement complètement faux, parce qu'un Non développeur ne peut pas lire le code, Bien qu'il puisse au moins partiellement lire et comprendre généré documentation, et cette façon qu'il peut savoir ce que testent les tests. C'est particulièrement important dans les cas où Le client comprend pleinement le domaine et tout simplement ne peut pas lire le code, et devient encore plus important lorsque l'unité Les tests testent également le matériel, comme dans le monde intégré, parce que vous testez des choses qui peuvent être vues.
Lorsque vous faites des tests d'unités, vous devez savoir si vous les écrivez pour vous (ou pour vos collègues), ou si vous les écrivez aussi pour d'autres personnes. Plusieurs fois, vous devriez écrire du code pour vos lecteurs , plutôt que pour votre commodité.
En développement de matériel mixte / logiciel comme dans ma société, les clients savent ce qu'ils veulent. Si leur périphérique de terrain doit effectuer une réinitialisation lors de la réception d'une certaine commande de bus, il doit y avoir un test d'unité qui envoie cette commande et vérifie si le périphérique a été réinitialisé. Nous le faisons ici en ce moment avec Nunit comme cadre de test de l'unité et certains logiciels personnalisés et matériels qui rendent les commandes d'envoi et de réception (et même des boutons de pression). C'est génial, car la seule alternative serait de faire tout ce qui manuellement.
Le client veut absolument savoir quels tests sont là et il veut même exécuter les tests lui-même. Si les tests ne sont pas correctement documentés, il ne sait pas ce que le test fait et ne peut pas vérifier si tous les tests qu'il pense qu'il aura besoin, y a-t-il besoin, et lors de l'exécution du test, il ne sait pas ce qu'il va faire. parce qu'il ne peut pas lire le code. Il connaît mieux le système de bus utilisé mieux que nos développeurs, mais ils ne peuvent tout simplement pas lire le code. Si un test échoue, il ne sait pas pourquoi et ne peut même pas dire ce qu'il pense que le test devrait faire. Ce n'est pas une bonne chose.
ayant documenté correctement les tests de l'unité, nous avons
- Documentation de code pour les développeurs
- Documentation test du client, qui peut être utilisée pour prouver que l'appareil fait ce qu'il devrait faire, c'est-à-dire ce que le client a commandé
- la possibilité de générer la documentation dans n'importe quel format, qui peut même être transmise à d'autres parties concernées, comme le fabricant
correctement dans ce contexte signifie: écrire une langue claire pouvant être comprise par des non-développeurs. Vous pouvez rester technique, mais n'écrivez pas les choses que vous pouvez comprendre. Ce dernier est bien sûr également important pour tout autre commentaire et n'importe quel code.
Indépendamment de notre situation exacte, je pense que c'est ce que je voudrais dans des tests unitaires tout le temps, même si ce sont des logiciels purs. Un client peut ignorer un test unitaire qu'il ne se soucie pas, comme des tests de fonction de base. Mais juste avoir les documents, il ne fait jamais de mal.
Comme je l'ai écrit dans un commentaire à une autre réponse: En outre, la documentation générée est également un bon point de départ si vous (ou votre chef ou votre collègue, ou le service des tests) souhaite examiner quels tests sont Là et ce qu'ils font, parce que vous pouvez le parcourir sans creuser le code.
+1, merci oregonghost! C'est une perspective intéressante car vos tests d'unité emploient plus d'une technologie.
Améliorer les tests de l'unité en tant que spécification exécutable est le point de Développement dirigé par le comportement : BDD est une évolution de TDD où les tests d'unité utilisent un langage omniprésent (une langue basée sur le domaine commercial et partagée par le Développeurs et les parties prenantes) et noms expressifs ( testcannotcreatureduplicatétry ) pour décrire ce que le code est censé faire. Certaines frameworks BDD ont poussé l'idée très loin et montrent l'exécutable écrit avec une langue presque naturelle, pour exemple .
Je conseillerais contre toute documentation détaillée distincte du code. Pourquoi? Parce que chaque fois que vous en avez besoin, il sera probablement très obsolète. Le meilleur endroit pour une documentation détaillée est le code lui-même (y compris les commentaires). BTW, tout ce que vous devez dire d'un test d'unité spécifique est documentation très détaillée.
Quelques pointeurs sur la manière de réaliser des tests auto-documentés bien:
Vous devez inclure, dans tous les noms de test: ce qui est testé, la situation sous test et le comportement attendu. Par exemple: Extrait de la logique commune dans la configuration / démonstration ou des méthodes d'assistance avec des noms descriptifs.
et pour compléter quelles autres réponses ont dit:
C'est génial si votre client / propriétaire / patron de produit a une très bonne idée de savoir ce qui devrait être testé et souhaite aider, mais les tests d'unité sont pas le meilleur endroit à faire ce. Vous devez utiliser des tests d'acceptation pour cette .
Les tests d'unités doivent couvrir des unités de code spécifiques (méthodes / fonctions dans des classes / modules), si vous couvrez plus de terrain, ils se transformeront rapidement en tests d'intégration, qui sont corrects et nécessaires aussi, mais si vous ne le faites pas. Séparez-les spécifiquement, les gens vont simplement les confondre et vous perdrez certains des avantages des tests unitaires. Par exemple, lorsqu'un test d'unité échoue, vous devez obtenir une détection instantanée du bogue (spécialement si vous suivez la convention de dénomination ci-dessus). Lorsqu'un test d'intégration échoue, vous savez qu'il y a un problème, et vous connaissez certains de ses effets, mais vous pourriez avoir besoin de déboguer, parfois pendant longtemps, de trouver ce que c'est.
Vous pouvez utiliser des frameworks de test unitaire pour des tests d'intégration si vous le souhaitez, mais vous devez savoir que vous ne faites pas de test unitaire et vous devez les conserver dans des fichiers / répertoires distincts.
Il existe de bons cadres d'essai d'acceptation / comportement (fitnesse, robot, sélénium, concombre, etc.) qui peuvent aider les personnes commerciales / domaines non seulement à lire, mais écrivent également les tests eux-mêmes. Bien sûr, ils auront besoin de l'aide des codeurs pour les amener à travailler (spécialement à partir de), mais ils pourront le faire, et ils n'ont rien besoin de connaître quoi que ce soit sur vos modules ou vos classes de fonctions. < / li>
Test__getaCountBountbalance__NullAccount__raisesNullargumentException ()
"Le code parle" est malheureusement complètement faux, car un non-développeur ne peut pas lire le code, alors qu'il peut au moins partiellement lu et comprennent la documentation générée, et il peut ainsi savoir quels tests testent. Ceci est particulièrement important dans les cas où le client comprend pleinement le domaine et ne peut tout simplement pas lire le code et est encore plus important lorsque l'unité teste également le matériel, comme dans le monde intégré, car vous testez ensuite des choses qui peuvent être vues.
@OREGONGHOST: Cela ressemble à vous avoir une certaine expérience avec le sujet. Souhaitez-vous élaborer votre opinion dans une réponse?
@OREGONGHOST - Généralement, les non-développeurs ne se soucieraient pas de tests unitaires. Ils veulent juste le produit. Votre point n'est donc pas vraiment Vaild indiquant qu'aucun développeur ne peut pas lire le code, bien sûr qu'ils ne peuvent pas. Sinon, ils feraient le projet.
et FINGLAS: J'ai ajouté une réponse, à la demande de Thorsten79.