frpaul1. Сначала пишешь набросок функции, и вот она работает.
Кстати, тесты мы пишем как?
На этом этапе ты придумываешь функцию: что она принимает, что она возвращает и какое у неё имя.
2. Пишешь для этой функции юнит-тест один.
Этим ты заготавливаешь среду для юнит-тестов к этой функции, то есть придумываешь, где они будут лежать (в каком файле и директории), как они будут запускаться, как они будут храниться внутри своего файла. Бывает, там нужно make подрубать, чтобы с верхушки проекта запускать тесты где-нибудь в глубине.
3. Потом функцию комментируешь внутри и запускаешь юнит-тест, и он показывает, что функция не работает.
Так ты удостоверяешься, что юнит-тест действительно проверяет функцию, а не просто работает сам по себе. Тут же смотришь, как он сообщает, что функция не работает, чтобы было видно причину отчётливо прямо из сообщения юнит-теста и не надо было лезть внутрь функции, чтобы понять, что в ней не сработало.
4. Потом функцию раскомментируешь внутри и запускаешь юнит-тест, он показывает, что функция работает.
Так ты всё отладил, всё работает, всё правильно пишется как в случае успеха, так и в случае ошибки и тебе не надо никуда лазить, чтобы это понять. Всё удобно запускается без поисков юнит-тестов в дебрях проекта.
Теперь наступает TDD, это когда сначала пишутся юнит-тесты все как бы для невидимой функции, а потом пишется функция, которая должна пройти эти юнит-тесты.
Например, ты знаешь, что функция при делении на ноль где-то внутри должна выпасть, а не продолжать работать. Ты пишешь сначала юнит-тест, который заставляет функцию выпасть, потом проверяешь, что он действительно показывает, что она не выпадает если там деление на ноль происходит. Потом идёшь в функцию и делаешь её такой, чтобы она выпадала при делении на ноль. И потом запускаешь юнит-тест и он показывает, что функция действительно выпадает при делении на ноль.
То есть основное правило: ты должен проверить, что юнит-тест как падает при сбое в функции, так и не падает при успешном выполнении функции.
А дальше уже выбираешь платформу для юнит-тестов. Есть doctest, unittest и py.test.
doctest - это очень быстрые (по разработке) тесты, и они включены в стандартную библиотеку питона.
unittest - это основные тесты (медленные по разработке, но развитые по возможностям), и они включены в стандартную библиотеку питона.
py.test - это сторонние тесты (очень модные и продуктивные), но они не включены в стандартную библиотеку питона.
Наверное, потом py.test включат в стандартную библиотеку, так как сделаны хорошо и все предпочитают их, а не unittest. Но unittest ты должен знать, потому что они основные в питоне. Ты просто на них напорешься где-нибудь, а выучить за пять минут их нельзя, это громадная платформа. Я учил их, наверное, целый месяц.