All comments

То, что можно наворотить это мы знаем, более того, можно наворотить и в док-тестах ;)

Я пользуюсь nose, из плюсов могу отметить хорошее обнаружение тестов - "то, что выглядит как тест, им и является" :), но вот меня смущает, что надо ставить его в зависимости (test_required в setuptools).

Кстати щас на python-dev идёт дискуссия по включение в stdlib какой-нибудь шутки для test discovery

> Меня вообще док-тесты раздражают...

С док-тестами можно рассказывать историю, т.е. одна из задач тестов (документирование) работает лучше. Классические юнит-тесты с этим справляются хуже, хотя они удобнее для написания отдельных коротких тестов.

Кстати, если неправильно использовать юнит-тесты, то можно наворотить - вообще потом не разгребешь (особенно со множественным наследованием и большими методами). :-)

Вот, кстати, не пробовал nose (http://code.google.com/p/python-nose/), хотя по докам не очень понятны преимущества именно при написании/чтении тестов.

Не, не надо утрировать. Тесты вещь нужная, но над ними, как и над кодом, надо хотя бы минимально работать и понимать что к чему. ;-)

А я-то уже дрожащими потными ручонками удалил все функции отсылки мыла со своих сайтов, которые там хостились, в поте лица искал дырку, а оказалось! Проще надо быть :) Тесты - нафиг :)

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

Гениальная фича! Жаль только все последнее время полюбили mysql, и на постгрес потихоньку забивают.

Ну в данном контексте можно и его использовать, нет проблем. :-)

Как говорится, +1 к защитному программированию.

А мне OpenID от яндекса нравится. Они поддерживают SREG и позволяют настроить какие поля раздавать и какие значения в них указывать.

Это правильно и, кстати, согласуется с принципами "защитного программирования" и соотв. делает твой код лучше - http://en.wikipedia.org/wiki/Defensive_programming