Давно хотел поиграться с Python-ом и Django, вот наконец выкроил немного времени на эту задачу. С синтаксисом Пайтона я был знаком и раньше, поэтому решил сразу покопаться с Django. Поставил фреймворк из репозитория, пробежался по базовым урокам, которые расположены на официальном сайте Django, и приступил к самому важному — к тестированию.

Я уверен, что в таких языках как Ruby и Python кодить без тестов не просто опасно, а очень опасно! Кстати, Пайтон приятно удивил наличием сразу нескольких библиотек для тестирования, я пока остановился на UnitTest и DocTest. UnitTest является клоном xUnit серии, поэтому особых сюрпризов не содержит. А вот DocTest оказался для меня чем-то новеньким. В итоге, я потратил несколько часов на его изучение.

Немного о плюсах DocTest

Сразу отмечу, что идея мне очень понравилась. Я посмотрел, как используются библиотеки для тестирования в самом Django и понял, что основная идея в том, чтобы успешно сочетать UnitTest и DocTest. Пока условно провел такую границу — если для теста требуется фикстура, то используем UnitTest, в противном случае делаем DocTest.

Очень понравилось, что для работы с DocTest-ами не нужно прыгать между несколькими файлами (по сути тест документирует код). Правда, пока, чтобы запустить тесты, приходится прыгать между консолью и NetBeans, но в ближайшее время планирую прикрутить к NetBeans возможность запускать тесты через горячие клавиши.

Очень понравился механизм сравнения возвращаемых величин с эталонными значениями. Ни для кого не секрет, что Python выводит в удобочитаемом виде содержимое любых базовых объектов будь то: массивы, списки, строки, числа или бог весть что еще. Поэтому, элементарный DocTest выглядит следующим образом:

>>> a =  [1, 2, 3]
>>> a
[1, 2, 3]

Правда просто? Немного поясню почему тест выглядит таким странным образом. В Пайтоне есть такая штука — интерактивный интерпритатор. Он позволяет запускать различные команды языка и сразу видеть на экране результат их выполнения. В примере выше записана одна простая сессия для интерактивного интерпритатора. Т.е. фактически мы бы увидели то же самое, если бы вводили команды с клавиатуры.

Простота использования библиотеки дает еще одно преимущество — скорость. Как не крути, а если речь идет о каком-то простом (базовом) тесте, то UnitTest — это довольно неудобная вещь. Он как бы специально подталкивает к написанию сразу чего сложного. А вот простой DocTest всего в две-три строки — это классно и удобно. Поэтому, хочется выразить команде разработчиков Пайтона большой респект за такое решение. Кстати, в одной статье написали, что DocTest — это как раз-таки «Python style», так что использование DocTest-ов, вроде как правильнее, чем UnitTest-ов.

Немного о непонятном

Я не особо вчитывался в документацию Django и поэтому для меня остался непонятным один момент — как правильно организовывать код проекта? Пока я пришел к такому выводу — проект состоит из набора приложений (application), каждое приложение состоит из одного и того же набора файлов: models.py, views.py, tests. py и некоторых других. Фишка в том, что все модели (классы) определяются в файле models.py. Т.е. правило: «один файл — один класс» здесь не работает. Для меня это дико, потому что я привык к PHP фреймворкам, а так как раз «один файл — это один класс».

Опять же, как я понял DocTest-ы запускаются только если они заданы в models.py, если создать любой другой файл и использовать в нем DocTest, то после выполнения команды «python manage.py test» — ничего не произойдет.

В заключение скажу, что в общем и целом тестирование через DocTest-ы оставляет приятные впечатления. Несмотря, на то, что выше я писал про скорость разработки, не нужно думать, что DocTest дает какую-то сверх производительности. Нет! Самое важное и прикольное — это как раз-таки не скорость, а комфорт. По крайне мере, мне показалось именно так.