Python doctest устраняет необходимость в юнит-тестах? - PullRequest
12 голосов
/ 15 апреля 2010

Один из разработчиков проекта, на котором я работаю, считает, что doctests так же хороши, как модульные тесты, и что если часть кода подвергается тестированию, его не нужно тестировать модульно. Я не верю, что это так. Кто-нибудь может привести несколько убедительных, идеально процитированных примеров за или против аргумента, что doctests заменяет необходимость юнит-тестов?

Спасибо -Daniel

РЕДАКТИРОВАТЬ: Может ли кто-нибудь предоставить ссылку, показывающую, что тестирование не должно заменять юнит-тестирование?

Ответы [ 6 ]

20 голосов
/ 15 апреля 2010

Я (ab) использовал doctest вместо unittest, когда я начал свой проект gmpy много лет назад - вы можете просмотреть его источники и убедиться, что вся функциональность тщательно протестирована с doctests (функциональность предоставляется C-кодированным расширением Python, и в прошлый раз, когда я инструктировал его для измерения покрытия, у меня было покрытие более 95%). Почему я это сделал? Потому что doctest был совершенно новым, как и gmpy, и мне было любопытно посмотреть, как далеко я смогу его продвинуть.

Ответ: действительно, очень далеко, но определенно не стоит (новинка изнашивается, но вы не хотите переписывать все свои тесты, поэтому тесты gmpy по-прежнему все-doctests). Чрезвычайная хрупкость док-тестов, когда даже самое маленькое исправление опечатки в сообщении нарушает тест, является настоящей проблемой, когда они подвергаются подобному насилию. Это похоже на традиционные интеграционные тесты, основанные на сравнении результатов с «золотым» (известным-хорошим) ожидаемым результатом: их легко написать с первого раза, но вы раскаетесь в свободное время после нескольких лет исправления случайных поломок тестов; ).

Если вы находите стиль unittest обременительным, есть и другие отличные альтернативы, которые по-прежнему означают для использования в модульных тестах, такие как py.test и Нос - doctest действительно предназначен для другой цели (поддержка документов, а не общих юнит-тестов), и хотя, конечно, стоит добавить в свой тест любые написанные вами тесты для целей документов батарея, она не стоит головной боли при испытаниях , заменяя единичные испытания ею.

6 голосов
/ 15 апреля 2010

Там действительно нет аргументов за или против тестов документов. Это просто тесты. На самом деле, начиная с Python 2.4, вы можете создавать тестовые наборы из ваших документов: http://docs.python.org/library/doctest.html#unittest-api

В некотором смысле вы можете рассматривать doc-тесты как подмножество модульных тестов, по крайней мере, с функциональной точки зрения.

Однако, документы Python предлагают использовать тесты для таких вещей, как:

  • примеров в документации
  • регрессионное тестирование
  • написание учебной документации

Их аргумент в том, что если вы пишете свои тесты в документации, вы будете вынуждены писать как лучшие документы, так и тесты. В отличие от того, когда вы пишете модульные тесты по отдельности - вы редко добавляете достаточное количество документации, и они имеют тенденцию к стагнации и устареванию.

См: http://docs.python.org/library/doctest.html#soapbox

Я полагаю, что для таких испытаний, как интеграционное тестирование, было бы сложнее написать. Однако, как вы можете видеть на python и Django - они широко используют doctests, что дает гораздо более понятную документацию и учебные пособия.

Все зависит от вашего проекта. Не существует «правильного» способа проверки.

Также я рекомендую взглянуть на книгу Code Complete 2 , поскольку вы можете обнаружить, что модульное тестирование - не лучший способ убедиться, что ваше программное обеспечение безошибочно.

5 голосов
/ 15 апреля 2010

В стандартной библиотеке Python есть конкретный пример, который убеждает меня, что одних только проверок не всегда достаточно, а именно модуль decimal. В нем более 60000 отдельных тестовых случаев (в Lib / test / decimaltestdata); если бы все они были переписаны как doctests, десятичный модуль стал бы действительно очень громоздким. Вполне возможно, что количество тестов может быть уменьшено, но при этом обеспечивается хорошее покрытие, но многие численные алгоритмы достаточно сложны, так что вам нужно огромное количество отдельных тестов, чтобы охватить все возможные комбинации ветвей.

2 голосов
/ 15 апреля 2010

Документы отлично подходят для некоторых целей

  • рабочая и актуальная документация
  • примеры тестов, встроенных в строки документации
  • всплески или фазы проектирования, когда API классов не совсем понятен

модульные тесты лучше в разных случаях:

  • когда вам нужна ясная и несколько сложная настройка / разборка
  • при попытке лучшего охвата всех дел, в том числе в угловых случаях
  • для обеспечения независимости испытаний друг от друга

Другими словами, по крайней мере для моего собственного использования, тесты документов хороши, когда вы сосредотачиваетесь на объяснении того, что вы делаете (документы, но также и этапы проектирования), но больше бремени, когда вы намереваетесь использовать тесты в качестве ремня безопасности для рефакторинг или покрытие кода.

0 голосов
/ 09 мая 2013

Я думаю, что это неправильный способ думать о докутах. Докуты - это документация. Они дополняют регулярные юнит-тесты. Думайте о документах-испытаниях как о примерах документации, которые должны быть проверены. Документы-тесты должны быть там, чтобы проиллюстрировать функцию для пользователей. Модульные тесты должны проверять весь код, даже в угловых случаях. Если вы добавите док-тесты для угловых случаев или десятки док-тестов, это просто затруднит чтение вашей строки документации.

0 голосов
/ 15 апреля 2010

возможно , чтобы реализовать полный набор модульных тестов с doctests. Тем не менее, doctests немного ограничены, и обычно лучше зарезервировать это для простых примеров документации и использовать более надежную структуру модульного тестирования (например, unittest) для реальных, подробных модульных тестов. *

Еще одним преимуществом unittest является то, что тестовая среда будет знакома кому-то из другой среды разработки, использующей JUnit, NUnit или аналогичную. Модуль doctest немного отличается.

...