Вообще-то subj.

Я тут погуглил маленько, и нашел только три системы:

unittest
doctest
py.test

unittest, как я понял, официальный и самый распространенный, doctest -- тоже официальный, но уже потихоньку устаревающий, py.test -- вообще экзотика, но, в принципе, возможности почти те же, что и у unittest. Известны кому-нибудь еще системы?

Здравствуйте, Аноним, Вы писали:

А>unittest, как я понял, официальный и самый распространенный, doctest -- тоже официальный, но уже потихоньку устаревающий, py.test -- вообще экзотика, но, в принципе, возможности почти те же, что и у unittest. Известны кому-нибудь еще системы?

Не сказал бы что doctest устаревающий. Это потрясающий инструмент в BDD и другого нет.

Ещё посмотрите вот эту презентацию: http://www.agilistas.org/presentations/pycon05/
От себя добавлю http://code.google.com/p/python-nose/

Здравствуйте, Daevaorn, Вы писали:

D>Не сказал бы что doctest устаревающий. Это потрясающий инструмент в BDD и другого нет.

Ну, насчет того, что он хорош — не могу согласиться.... Тестов у меня обычно бывает много (объем тестов в 5-10 раз превышает объем исходного кода). Если каждый снабдить еще и "читабельным" пояснением — это будет такой прицеп, что у использующего мой код просто руки опустятся при виде такого "doc". Если не снабдить — то это будет чистый "test", без приставки "doc". По сути, тому, кто делает

>>>help(my_function)

надо просто знать, что делает my_function; Представьте себе, что было бы, если бы набрав в NumPy

>>>help(transpose)

вы бы вместо простого и ясного пояснения, что transpose транспонирует матрицу, и пары примеров, получали бы полный набор тестов: для пустых матриц, для векторов, для строк, для многомерных массивов.... То есть, судя по help, те два примера, которые в нем имеются, подходят для doctest, но я сильно сомневаюсь, что это ВЕСЬ набор тестов. Во всяком случае, я бы к ним добавил еще десяток-другой.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Daevaorn, Вы писали:

D>>Не сказал бы что doctest устаревающий. Это потрясающий инструмент в BDD и другого нет.

А>Ну, насчет того, что он хорош — не могу согласиться.... Тестов у меня обычно бывает много (объем тестов в 5-10 раз превышает объем исходного кода). Если каждый снабдить еще и "читабельным" пояснением — это будет такой прицеп, что у использующего мой код просто руки опустятся при виде такого "doc". Если не снабдить — то это будет чистый "test", без приставки "doc". По сути, тому, кто делает


Мне кажется вы не до конца поняли их суть. Док тесты может вообще находиться в отдельном модуле и никак не "засорять" док-стринг конкретной функции/класса. Удобство их в том, что они просты и удобны в написании и не порождают лишние сущности при написании. Плюс позволяют реализовать Behavior Driven Development, пусть и не так красиво как в Ruby например.

Здравствуйте, Аноним, Вы писали:

А>Вообще-то subj.

А>Я тут погуглил маленько, и нашел только три системы:

А>

А>unittest
А>doctest
А>py.test
А>

Использую unittest, мне удобно тем, что есть поддержка в pydev.

Здравствуйте, Daevaorn, Вы писали:

D>Мне кажется вы не до конца поняли их суть.

Видимо, да

Цитата (прямо из описания, найденного в исходнике)

Then running the module as a script will cause the examples in the
docstrings to get executed and verified:

Т.е. основная задача все же была — тесты, которые находятся прямо в док-стринг

D>Док тесты может вообще находиться в отдельном модуле и никак не "засорять" док-стринг конкретной функции/класса.

Тогда есть ли смысл вообще использовать такую сложную форму — "выцарапывать" тесты из док-стринг? Мне поначалу показалось это интересным вариантом, НО — все тесты ИМХО в док-стринг не стоит загонять, тот, кому их придется читать — взвоет. Т.е. ИМХО конкретно эта фича лишняя...

D>Удобство их в том, что они просты и удобны в написании и не порождают лишние сущности при написании. Плюс позволяют реализовать Behavior Driven Development, пусть и не так красиво как в Ruby например.

Взаимодействие с пользователем, т.е. вывод в консоль (но не ввод, конечно) — да, описывается проще. На первый взгляд, потому что в unittest для этого потребуется писать код, перенаправляющий ввод/вывод. А на второй взгляд — нет, потому что, когда пишешь программу с выводом в консоль, то описываешь сообщения, которые она выдает, в виде констант или даже функций, и, если я написал:

def some_error(detailes):
    # Процедура, которая выводит пользователю сообщение об ошибке.
    # detailes -- дополнительная информация (код ошибки, traceback ит.п.)
    ......
    # Возвращает строку, предназначенную для вывода в консоль в качестве
    # сообщения об ошибке
    return msg_string

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

assert caught_output==some_error(expected_detailes)

А в doctest — будь любезен, пиши открытым текстом, что ты ожидаешь увидеть. И если в тексте сообщения ты изменил хоть одно слово, или хотя бы запятую — нужно править все тесты, в которых ты проверяешь сообщения. Это меня, честно говоря, не очень радует....

То есть, я бы сказал, что doctest полезен для тестирования примеров, которые приводятся в docstring, но никак не для тестирования кода

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Daevaorn, Вы писали:

D>>Мне кажется вы не до конца поняли их суть.

А>Видимо, да

Как-то вы всё равно скатились до банальных "примеров кода" и "вывода в консоль".

За доктестами скрыта целая парадигма тестирования — простого тестирование поведения. Которая имеет право на жизнь и живет. Есть достаточно крупные питонячьи проекты, тесты в которых в большинстве своем это именно доктесты, но оформленные в виде отдельных модулей. И вы не поверит — это удобно! Но конечно учитывая ограничения самих доктестов их инфраструктуры.

Так что тоже вполне себе актуальный инструмент тестирования и не стоит его недооценивать.

Здравствуйте, Daevaorn, Вы писали:

D>За доктестами скрыта целая парадигма тестирования — простого тестирование поведения. Которая имеет право на жизнь и живет.
Так ведь unittest, JUnit, cppUnit и им подобные вроде бы тоже тестируют поведение. В чем отличия? Посмотрел на IBM.com статью и, честно говоря, не понял, чем BDD отличается от TDD. Только тем, что вместо "test" говорим "should"?

Здравствуйте, Аноним, Вы писали:

А>Так ведь unittest, JUnit, cppUnit и им подобные вроде бы тоже тестируют поведение. В чем отличия? Посмотрел на IBM.com статью и, честно говоря, не понял, чем BDD отличается от TDD. Только тем, что вместо "test" говорим "should"?

Просто doctest растет из REPL и для тех кто привык в нем работать это очень удобно.