Помню, на меня неизгладимое впечатление произвел стандартный test/test_bool.py
Класс на два значения - а столько тестов к нему.

Ferroman
Неплохо проиллюстрировано хотя бы в самом Питоне. У него весьма приличное покрытие.
Основная выгода - когда пишешь, уверен что существующую функциональность не ломаешь.
Еще баги на тестах удобно ловить. Раз поймал - пофиксил и в дальнейшем у тебя на этого гада тест готов, который сам запускается и проверяется.

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

Спасибо, интересно.
Попробую.
А доктесты используешь? Стандартные тесты, или что-то со стороны?

Доктесты - использую иногда. Хороши для мелких четко очерченных либ. Они мне очень нравяться, но не ко всему подходят.
Наверное, лучшая система юниттестов на сегодня - nose. Писать можно и обычным unittest, а вот запускать - nosetests однозначно.
Далее, без мокеров не обойтись. Создавать их каждый раз вручную - неблагодарный труд. После долгих переборов остановился на mocker.

И еще. Если уж браться за дело всерьез, нужен continious integration. Если по русски - завести buildbot и законфигурировать его на запуск unittests после каждого commit. С рассылкой гневных писем и раздачей розовых слонов тем, кто поломал. Если нет системы, запускающей тесты автоматом - люди ленятся и начинают забивать. А подход работатет только в том случае, если поломаный транк автоматически означает авральную ситуацию. На человеческую сознательность можно надеяться только в очень маленьких и очень ответственных коллективах - то есть не “как обычно”.

Понятно, спасибо.

Андрей Светлов
Доктесты - использую иногда. Хороши для мелких четко очерченных либ. Они мне очень нравяться, но не ко всему подходят.

Я использую для мелких вещей, для которых писать выделенные тесты – избыточно. Например.

Писать можно и обычным unittest, а вот запускать - nosetests однозначно.

+1, именно так и делаю :)