Un collègue développeur sur un projet que je suis sur croit que les doctestes sont aussi bons que des tests unitaires et que si un morceau de code est doctau, il n'a pas besoin d'être testé sur l'unité. Je ne crois pas que cela soit le cas. Quelqu'un peut-il fournir un peu de solide, idéalement cité, des exemples, que ce soit pour ou contre l'argument selon lequel les Doctest remplacent le besoin de tests d'unité?
merci -Daniel
EDIT: Quelqu'un peut-il fournir une référence montrant que la DocTesting ne doit pas remplacer les tests d'unité?
6 Réponses :
C'est possible pour implémenter une suite de tests d'unité complète avec des doctestes. Cependant, les doctestes sont un peu limités et il est généralement préférable de réserver cela pour des exemples de documentation simples, et utilisez un cadre de test d'unités plus robuste (par exemple, Un autre avantage de unitest ) pour les tests de l'unité réels et détaillés.
Unitest est que le cadre de test sera familier à quelqu'un d'un environnement de développement différent qui utilise Junit, Nunit ou similaire. Le module doctest est un peu différent.
Nous avons actuellement un mélange de doctest et unittest et n'avons absolument aucune intention d'aller tous pour l'un ou l'autre. Nos doctestes sont présents pour montrer des exemples et pour appliquer que la documentation et le code sont en synchronisation, les plus utiles pour exercer réellement tout le code. Le développeur estime que si un doctest est écrit, il n'est pas nécessaire de ne pas nécessairement être des unités pour le même code. Le dernier point est où je suis en désaccord
Il n'y a vraiment aucun argument pour ou contre des tests DOC. Ils sont simplement des tests. En fait, à partir de Python 2.4, il existe un moyen de créer des costumes de test de l'unité de vos doctestes: http://docs.python.org/library/doctest.html#unittest-api
Dans un sens, vous pouvez penser à DOC-TESTS en tant que sous-ensemble de tests unitaires, du moins du point de vue fonctionnel.
Cependant, Python Docs suggère d'utiliser des doctestes pour des choses comme:
Leur argument est que si vous écrivez vos tests dans la documentation, vous serez obligé d'écrire à la fois de meilleurs documents et tests. Contrairement au lorsque vous écrivez des tests d'unité séparément - vous ajoutez rarement suffisamment de documentation et ils ont tendance à stagner et à sortir de la date.
Voir: http://docs.python.org/library/doctest.html#soapbox
J'imagine que les doctestes seraient plus difficiles à écrire pour des tests d'intégration. Cependant, comme vous pouvez le constater sur Python et Django - ils utilisent beaucoup de doctestes, ce qui donne une documentation et des tutoriels beaucoup plus compréhensibles.
Tout dépend de votre projet. Il n'y a pas de «bon» moyen de tester.
Aussi, je vous recommande de regarder Code Complete 2 Book, car vous pouvez constater que le test de l'unité n'est pas le meilleure façon de vous assurer que votre logiciel est sans faute.
L'intention de cette question ne devait pas être ni pour ni contre des doctestes, mais si les doctests peuvent remplacer les unitest. Personnellement, je ne pense pas que cela soit le cas, mais j'étais curieux des opinions des autres. Code complet 2 est un excellent livre et je recommande que chaque développeur le lait. Encore une fois, l'objectif de cette question n'était pas de savoir comment faire des preuves de balle logicielles.
Eh bien, comme certaines des autres personnes ont souligné, ils peuvent remplacer les tests d'unité, mais avec quelques douleurs. Personnellement pour moi d'écrire du code dans une grande chaîne commentée est ce qui ne jive pas. D'autre part, vous pourriez faire tout ce que vous vouliez avec des doctestes que vous pourriez faire avec des informations.
i (ab) utilisé Réponse: très loin en effet - mais ne valent certainement pas la peine (la nouveauté s'use, mais vous ne voulez pas réécrire tous vos tests, c'est pourquoi les tests de GMPY sont toujours tous des doctests). La fragilité extrême des doctestes, où même la faute de frappe la plus petite dans un message brise le test, est une véritable préoccupation quand elles sont maltraitées de cette façon. C'est un peu comme des tests d'intégration traditionnels basés sur la comparaison de la sortie avec une sortie attendue "dorée" (bien connue): facile à écrire la première fois, mais vous vous repentirez à loisir après quelques années de rupture de test gratuite; - ).
Si vous trouvez doctest au lieu de Unitest , retour quand j'ai commencé mon GMPY Projet Il y a de nombreuses années - Vous pouvez parcourir ses sources et voir que toutes les fonctionnalités sont minutieusement testées avec des doctestes (la fonctionnalité fournie par une extension de Python CoDed et dernier. Le temps que j'ai instruit pour la mesure de la couverture J'étais plus de 95% de couverture). Pourquoi ai-je fait ça? Parce que DOCTESTEST était neuf, tel que c'était gmpy , et j'étais curieux de voir jusqu'où je pourrais le pousser.
Unittest STYLE STYLETERE, il existe d'autres excellentes alternatives qui sont toujours Doctest est vraiment destiné à un objectif différent (soutenir les documents, non génériques tests de l'unité) et, bien que cela vaut bien sûr, il convient d'ajouter des doctests que vous avez écrites < EM> Pour des fins de Documents à votre batterie de test, c'est pas omettez les maux de tête de maintenance de test remplacement de tests d'unité avec celui-ci.
Il ne s'agit pas de mentionner que les doctestes ne testent pas réellement la sortie d'une fonction. Ils testent la REC () de la sortie de la fonction. Parfois, la forme de chaîne d'un objet est une perte par rapport à ce qu'est un normal ou Assertequal serait testé, entraînant un test qui passe lorsqu'il ne devrait pas le faire. Le formulaire de chaîne peut également avoir des différences sans importance, telles que les clés dictées étant dans un ordre différent de celui attendu.
"Ils testent la REP () de la sortie de la fonction." True, mais vous pouvez le faire plutôt pour simuler des assertables: >>> résultat == attendu suivi de true
Il y a un exemple concret dans la bibliothèque standard de Python qui me persuade que les doctestes seuls ne sont pas toujours suffisants, à savoir le module décimal . Il dispose de plus de 60000 tests individuels (en lib / test / décimaltestdata); Si tous ceux-ci étaient réécrites comme des doctestes, le module décimal deviendrait vraiment très difficile à manier. Il est possible que le nombre de tests pourrait être glacé tout en donnant une bonne couverture, mais bon nombre des algorithmes numériques sont suffisamment compliqués que vous besoin énorme nombre de tests individuels pour couvrir toutes les combinaisons possibles des branches.
Il est possible d'écrire vos doctests dans un fichier séparé. Il peut résider n'importe où et il suffit de répondre à la référence Sys.Path pour importer du fichier / module à tester.
Les doctestes sont parfaits pour certaines utilisations
Les tests unitaires sont meilleurs dans les cas différents:
En d'autres termes, au moins pour mon propre usage, les doctests sont formidables lorsque vous vous concentrez sur l'explication de ce que vous faites (DOCS, mais aussi des phases de conception), mais plus de fardeau lorsque vous avez l'intention d'utiliser des tests comme ceinture de sécurité pour refactoring ou couverture de code.
Pouvez-vous citer une référence à ce sujet par hasard?
@Daniel: Il s'agit d'un usage personnel des deux types de tests dans les projets que j'ai travaillé. Heures passées à réparer des tests après refactoring et ainsi de suite. Quel genre de référence cherchez-vous? Entrées de blog ?
Réponse la plus satisfaisante à mon point de vue. Indique clairement où chaque outil est logique d'être utilisé.
Je pense que c'est la mauvaise façon de penser aux doctestes. Les doctestes sont des documents. Ils complètent des tests d'unités réguliers. Pensez aux doctests comme des exemples de documentation qui se produisent à être testés. Les doctestes doivent être là pour illustrer la fonction aux utilisateurs humains. Les tests de l'unité doivent tester tout le code, même les cas d'angle. Si vous ajoutez des doctestes pour les cas d'angle ou des dizaines de doctestes, cela permettra de rendre votre doctrine difficile à lire.
Vous pouvez ajouter des caisses de coin en tant que testFile, par exemple. doctest.tsfile ("exemple.txt"). Mais par exemple, se moquer d'une base de données, etc. serait difficile à faire à Doctest afin que le type de cas d'angle soit mieux fait avec des tests unitaires.
Stackoverflow.com/Questtions/361675/python-Doctest-vs-unittes t
"Je ne crois pas que cela soit le cas." Pourquoi ne pas créer ou trouver une classe trop complexe pour les doctestes? Pourquoi dépend de la croyance lorsque vous pouvez créer un exemple qui fait votre point?
@iAma, merci pour le lien. Je n'ai pas vu cela lors de la publication. @ S.Lott, nous sommes en train de montrer une preuve au développeur
"Fournir une référence"? Voulez-vous dire «fournir un exemple»? Veuillez réviser cette modification si vous ne voulez que un exemple? Sinon, quel type de «référence» recherchez-vous?