Python doctest устраняют необходимость модульных тестов?
Такой же разработчик на проекте, я иду, полагает, что doctests так же хороши как модульные тесты, и что, если часть кода является doctested, это не должно быть протестировано на единицу. Я не полагаю, что это имеет место. Кто-либо может обеспечить некоторое тело, идеально процитированное, примеры любой за или против аргумента, что doctests заменяют потребность в модульных тестах?
Спасибо - Daniel
Править: Кто-либо может обеспечить ссылку, показывающую, что doctesting не должен заменять поблочное тестирование?
5 ответов
Я (ab) использовал doctest вместо unittest , когда много лет назад начал свой проект gmpy - вы можете просмотреть его исходники и убедитесь, что вся функциональность тщательно протестирована с помощью doctests (функциональность предоставляется расширением Python с кодом C, и в прошлый раз, когда я использовал его для измерения покрытия, у меня было более 95% покрытия). Зачем я это сделал? Поскольку doctest был совершенно новым, как и gmpy , мне было любопытно посмотреть, как далеко я смогу его продвинуть.
Ответ: действительно очень далеко - но определенно того не стоит (новизна стирается, но вы не хотите переписывать все свои тесты, поэтому тесты gmpy по-прежнему являются полностью доктестами). Чрезвычайная хрупкость тестов, когда даже самая маленькая опечатка в сообщении нарушает проверку, становится настоящей проблемой, когда ими злоупотребляют. Это что-то вроде традиционных интеграционных тестов, основанных на сравнении результатов с «золотым» (заведомо хорошим) ожидаемым результатом: легко написать с первого раза, но вы будете раскаиваться на досуге после нескольких лет исправления беспричинных сбоев в тестах; ).
Если вы находите стиль unittest обременительным, есть и другие отличные альтернативы, которые по-прежнему предназначены для использования в модульных тестах, например py.test и нос - doctest действительно предназначен для другой цели (поддержка документации, а не общих модульных тестов), и хотя, конечно, стоит добавить любые написанные вами доктесты для документации к вашей тестовой батарее, это не стоит головных болей по тестированию и обслуживанию , заменяющих им модульные тесты.
doctests отлично подходят для некоторых целей
- рабочая и актуальная документация
- образцы тестов, встроенные в строки документации
- spikes или этапы проектирования когда API классов не совсем понятен
юнит-тесты лучше в разных случаях:
- когда вам нужна ясная и несколько сложная настройка / демонтаж
- при попытке получить лучшее покрытие всех случаев, включая угловые случаи
- для обеспечения независимости тестов друг от друга
Другими словами, по крайней мере, для моего собственного использования, doctests хороши, когда вы сосредоточены на объяснении того, что вы делаете (документы, но также и на этапах разработки), но больше обременительны, когда вы намереваетесь используйте тесты в качестве ремня безопасности для рефакторинга или покрытия кода.
Возможно реализовать полный набор модульных тестов с помощью doctests. Однако doctests немного ограничены, и обычно лучше оставить это для простых примеров документации и использовать более надежную среду модульного тестирования (например, unittest ) для реальных, подробных модульных тестов.
Еще одно преимущество unittest заключается в том, что среда тестирования будет знакома тем, кто работает в другой среде разработки, использующей JUnit, NUnit или аналогичные. Модуль doctest немного отличается.
В стандартной библиотеке Python есть конкретный пример, который убеждает меня в том, что одних тестов не всегда достаточно, а именно десятичный модуль. Он имеет более 60000 отдельных тестовых случаев (в Lib / test / decimaltestdata); если бы все это было переписано как доктесты, десятичный модуль действительно стал бы очень громоздким. Возможно, количество тестов можно сократить, но при этом обеспечить хорошее покрытие, но многие численные алгоритмы настолько сложны, что вам потребуется огромное количество отдельных тестов, чтобы охватить все возможные комбинации ветвей.
На самом деле нет никаких аргументов за или против doc-тестов. Это просто тесты. Фактически, начиная с python 2.4, есть способ создавать комплекты модульных тестов из ваших тестов: http://docs.python.org/library/doctest.html#unittest-api
В В некотором смысле вы можете рассматривать doc-тесты как подмножество модульных тестов, по крайней мере, с функциональной точки зрения.
Однако документы python предлагают использовать тесты для таких вещей, как:
- примеры в документации
- регрессионное тестирование
- написание учебной документации
Их аргумент состоит в том, что если вы пишете свои тесты в документации, вы будете вынуждены напишите как лучшие документы, так и тесты. В отличие от того, когда вы пишете модульные тесты отдельно - вы редко добавляете достаточную документацию, и они имеют тенденцию к застою и устаревают.
См .: http://docs.python.org/library/doctest.html#soapbox
Я полагаю, что для таких вещей, как интеграционное тестирование, будет сложнее написать тесты. Однако, как вы можете видеть на python и Django, они широко используют тесты документации, что дает гораздо более понятную документацию и руководства.
Все зависит от вашего проекта. Не существует "правильного" способа проверки.
Также я рекомендую взглянуть на книгу Code Complete 2 , так как вы можете обнаружить, что модульное тестирование - не лучший способ убедиться, что ваше программное обеспечение исправно.