Python - doctest vs. unittest [закрито]

Я намагаюся почати з тестування модулів на Python, і мені було цікаво, чи хтось може пояснити переваги та недоліки doctest та unittest.

Для яких умов ви б використовували кожного?

Обидва цінні. Я використовую як doctest, так і ніс, займаючи місце unittest. Я використовую doctest у випадках, коли тест дає приклад використання, який фактично корисний як документація. Як правило, я не роблю ці тести всеосяжними, спрямовані лише на інформативність. Я ефективно використовую doctest у зворотному порядку: не для перевірки правильності коду на основі мого doctest, а для перевірки правильності моєї документації на основі коду.

Причина полягає в тому, що я знаходжу, що всебічні документи будуть занадто сильно захаращувати вашу документацію, тож ви закінчитеся або з непридатними документами, або з неповним тестуванням.

Насправді тестування коду , мета - ретельно перевірити кожен випадок, а не проілюструвати те, що робиться на прикладі, що є іншою метою, яку, на мою думку, краще досягають інші рамки.

Я використовую unittest майже виключно.

Раз у раз я покладу деякі речі в docstring, який можна використовувати doctest.

95% тестових випадків є одиничними тестами.

Чому? Мені подобається зберігати доктрини дещо коротше і більш чітко. Іноді тестові випадки допомагають уточнити докстринг. Більшість випадків тестові приклади програми занадто довгі для докстрингу.

Ще одна перевага doctesting полягає в тому, що ви переконайтеся, що ваш код виконує те, що говорить ваша документація. Через деякий час зміни програмного забезпечення можуть змусити вашу документацію та код робити різні дії. :-)

Я працюю біоінформатором, і більша частина коду, який я пишу, - це сценарії "один раз, одне завдання", код, який буде виконуватися лише один-два рази, і який виконує одне конкретне завдання.

У цій ситуації написання великих тестів може бути надмірним, а доктести - корисним компромісом. Вони швидше писати, і оскільки вони зазвичай включені в код, вони дозволяють постійно стежити за тим, як повинен вести себе код, не маючи відкритого іншого файлу. Це корисно при написанні невеликого сценарію.

Крім того, doctests корисні, коли вам доведеться передати свій сценарій досліднику, який не є експертом у програмуванні. Деяким людям дуже важко зрозуміти, як структуровані одиничні тести; з іншого боку, doctests - прості приклади використання, тому люди можуть просто скопіювати та вставити їх, щоб побачити, як ними користуватися.

Отже, для відновлення моєї відповіді: доктести корисні, коли ви повинні писати невеликі сценарії та коли вам потрібно передавати їх або показувати дослідникам, які не є комп'ютерними науковцями.

Якщо ви тільки починаєте з ідеї тестування одиниць, я б почав з того, doctestщо це так просто у використанні. Це, природно, забезпечує певний рівень документації. А для більш всебічного тестування doctestви можете розмістити тести у зовнішньому файлі, щоб він не захаращував вашу документацію.

Я б запропонував, unittestякщо ви перебуваєте на тлі використання JUnit або чогось подібного, де ви хочете мати можливість писати одиничні тести загалом так само, як ви були в іншому місці.

Я використовую виключно unittest; Я думаю, що doctest занадто захаращує основний модуль. Це, мабуть, стосується написання ретельних тестів.

Використання обох - допустимий і досить простий варіант. doctestМодуль забезпечує DoctTestSuiteіDocFileSuite методи , які створюють UnitTest-сумісні Тести з модуля або файлу, відповідно.

Тож я використовую і те, і зазвичай використовую doctest для простих тестів з функціями, які вимагають невеликої або ніякої настройки (прості типи аргументів). Насправді я думаю, що кілька тестів на doctest допомагають документувати функцію, а не применшувати її.

Але для більш складних випадків і для більш всебічного набору тестових випадків я використовую unittest, який забезпечує більший контроль та гнучкість.

Я не використовую doctest як заміну для unittest. Хоча вони трохи перетинаються, два модулі не мають однакової функції:

• Я використовую unittestяк блок тестування одиниці, тобто він допомагає мені швидко визначити вплив будь-якої модифікації на решту коду.

• Я використовую doctestяк гарантію, що коментарі (а саме docstrings) як і раніше стосуються поточної версії коду.

Широко задокументовані переваги розвитку тестових програм я отримую unittest. doctestвирішує набагато більш тонку небезпеку застарілих коментарів, що вводять в оману підтримку коду.

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

Doctestможе часом призвести до неправильного результату. Особливо, коли вихід містить послідовності втечі. Наприклад

def convert():
    """
    >>> convert()
    '\xe0\xa4\x95'
    """
    a = '\xe0\xa4\x95'
    return a
import doctest
doctest.testmod()

дає

**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
    convert()
Expected:
    'क'
Got:
    '\xe0\xa4\x95'
**********************************************************************
1 items had failures:
   1 of   1 in __main__.convert
***Test Failed*** 1 failures. 

Також не перевіряє тип виводу. Він просто порівнює вихідні рядки. Наприклад, він зробив раціональний тип, який друкує так само, як ціле число, якщо це ціле число. Тоді припустимо, у вас є функція, яка повертається раціонально. Таким чином, doctest не буде відрізнятись, якщо вихід є раціональним цілим числом або цілим числом.

Я віддаю перевагу системам на основі відкриття ("ніс" і "py.test", використовуючи колишню в даний час).

doctest приємно, коли тест також хороший як документація, інакше вони, як правило, занадто захаращують код.