Зачем писать тесты? Когда их писать? Когда их не писать? Хабр был и остается неравнодушен к этим и другим вечным вопросам, и не один хабровчанин провел бессонную ночь, придумывая убедительные на них ответы (чтобы оппоненты, наконец, заткнулись).

Я решил взять противника не умением, а числом, и поэтому вот вам 19 причин, по которым писать тесты все-таки стоит (в хронологическом порядке). Итак, тесты

Топик — вольный перевод статьи Vim Plugins You Should Know About, Part I: surround.vim Петериса Круминса.

UPD: вторая часть

Что такое плагин surround.vim? Вот что говорит о нем автор, Тим Поп (Tim Pope):

Surround.vim работает со всем, что «окружает»: скобками, кавычками, тегами XML и т.п. Плагин предоставляет сочетания клавиш, которыми можно легко удалять, изменять и добавлять пары таких окружающих элементов.

Программист зверь ленивый, поэтому всё, что будет делаться больше одного раза надо непременно заскриптовать.

Я уже некоторое время ковыряю TDD и задача постоянного контроля качества для меня становится всё актуальней. Особенно при пополнении команды новыми разработчиками.

Сначала я запускал тесты руками: save, switch, $ nosetests. Потом к тестам добавились проверялки качества кода и пришлось всё засунуть в скрипт:
pyflakes *.py
pep8 *.py
pylint *.py
nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:
while true; do
inotifywait -e modify project/*.py -qq; clear
./do_tests
done

Тут я стал более-менее доволен происходящим и даже на некоторое время расслабился. Но ведь программист кроме того, что ленив ещё и горд, поэтому результаты хочется кому-нибудь показать. Чтобы вести историю происходящего (которая очень помогает когда заходит начальник начальника и спрашивает: «ну-с, чем вы занимались последний месяц?») уже есть система контроля версий. Но она показывает только, что сделано и не даёт обзора успешности каждой ревизии. Получается что код лежит, но непонятно в каком он состоянии и что где ещё надо сделать.

Кроме того довольно тяжело следить за коллегами, которые тоже могут что-то сделать и забыть прогнать тесты, в результате в репозитории лежит битый код, не прошедший code review и при очередном pull может внезапно начаться clusterfuck.

И тут очень вовремя kmmbvnr@lj выпустил скринкаст, в котором он демонстрировал интеграцию тестирования для django-проектов с сабжем Jenkins (бывш. Hudson). Посмотрел я на все эти красоты, графики и отчёты и тоже захотел чтобы всё само пело и играло. Но у него django-jenkins, как и следует из названия, встраивается в джангу и генерит отчёты используя хитрую систему. Мой проект до джанги не дорос и скорее всего не дорастёт — это достаточно тривиальное WSGI-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

Воскресенье я на это убил, но в целом всё довольно прямолинейно и теперь у меня есть симпатичные отчёты:



Что внутри?

Итак, что же это значит, когда кто-либо говорит, что foo выглядит как pythonic? Что значит, когда кто-либо смотрит в наш код и говорит, что он unpythonic? Давайте попробуем разобраться.

В Python-сообществе существует неологизм pythonic, который можно трактовать по разному, но в общем случае он характеризует стиль кода. Поэтому утверждение, что какой-либо код является pythonic, равносильно утверждению, что он написан в соответствии с идиома Python’a. Аналогично, такое утверждение в отношении интерфейса, или какой-либо функциональности, означает, что он (она) согласуется с идиомами Python’a и хорошо вписывается в экосистему.

Напротив, метка unpythonic означает, что код представляет собой грубую попытку записать код какого-либо другого языка программирования в синтаксисе Python, а не идиоматическую трансформацию.

Понятие Pythonicity плотно связано с минималистической концепцией Python’a и уходом от принципа «существует много способов сделать это». Нечитабельный код, или непонятные идиомы – все это unpythonic.

При переходе от одного языка к другому, некоторые вещи должны быть «разучены». Что мы знаем из других языков программирования, что не будет к месту в Python’e?

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

Большинство примеров кода не привязаны к какому-либо конкретному языку программирования, но для наглядности я буду использовать PHP.

Итак, поехали.

Третья часть заметок об объектной системе python'a (первая и вторая части). В статье рассказывается о том, почему c.__call__() не то же самое, что и c(), как реализовать singleton с помощью метаклассов, что такое name mangling и как оно работает.

Вторая часть заметок об объектной системе python'a (первая часть тут). В этой статье рассказывается, что такое классы, метаклассы, type, object и как происходит поиск атрибутов в классе.

Несколько заметок об объектной системе python'a. Рассчитаны на тех, кто уже умеет программировать на python. Речь идет только о новых классах (new-style classes) в python 2.3 и выше. В этой статье рассказывается, что такое объекты и как происходит поиск атрибутов.

Так сложилось, что я много раз рассказывал о том, что такое SaaS и что в нем хорошего, как на различных it-конференциях, так и в кулуарных беседах, но до сего момента писать по теме не приходилось. При этом модель SaaS во-первых для меня по сути родная, учитывая сферу деятельности, а во-вторых является одним из основных трендов в современных веб-технологиях. В связи с этим, хочу поговорить о SaaS, как о таковом, а в перспектике, если окажется интересным, о частных аспектах. По сути материал о базисных вещах, но именно такого понимания многим не хватает. А о сложном надо хотя бы пытаться говорить просто. Помогает.

Сразу хочу сказать одну вещь, SaaS — это специализированный термин и, если начинать в нем копаться, сложный. Он может навести не только тоску, но и определенный благоговейный ужас. Но на самом деле штука это простая. Чтобы пользоваться каким-то SaaS-продуктом, в том числе нашим, понимать глубинный, да даже и поверхностный смысл данного термина совершенно не обязательно. Более того, когда uCoz создавался, никто из самих разработчиков даже не слышал подобного слова. Просто появлялись продукты, имеющие по своей сути общую модель, и потом ее стали как-то классифицировать, выделять особенности, плюсы, минусы.
Если своим призванием или увлечением вы сделали веб-технологии, или же задумываетесь о том, какой тип продуктов лично для вас подходит более всего, какие наиболее перспективны и т.п., все это может быть интересно и полезно.