Прагматичные тесты
Мой путь с тестами длительное время не пересекался, мы находились в одной вселенной. Но если и запускал чьи-то тесты, то это было либо случайно, либо просто ради фана посмотреть на бегущие строки на экране.
Zope и Plone имели тесты, но мы в основном занимались внедрением, а свои небольшие продукты писались в моменты когда времени на покрытие не было, да и не умели. Когда начали писать что-то свое на Zope3 и позже под GAE, то тесты постепенно появились. Причем использовали уже все что можно, включая Selenium тестирование AJAX интерфейса.
Написания тестов — это всегда момент взятия ответственности на себя. Можно для мелкой функции написать десяток тестов, а можно обойтись только одним. И в отличии от самого кода который можно оценить по очень простому критерию если он работает, то он достаточен, программист принимает решение сам сколько и каких их должно быть для каждой конкретной ситуации.
Тесты можно писать вечно, но чем больше тестов тем больше их надо будет исправить если вдруг требования поменяются. Да и видимого результата тесты не дают. Программист не видит прогресса, не видит добавления новой функциональности, но ему надо принять решение какой именно аспект работы существующего кода надо покрыть. Бывают еще отчеты о покрытии кода тестами, но это уже другая история.
Постепенно сформировалось следующее мнение:
- Тесты может быть писать приятно и интересно, но до тех пор пока сотрудник не начнет получать от этого удовольствие его не заставишь это делать.
- Случаев когда тесты нужны обязательно не так много — это места интеграции с другими технологиями. Например в вебе к ним относятся публичные API, то к чему обращаются AJAX клиенты.
- Тесты не защищают от плохого кода, они только гарантируют что он будет работать.
- Написание тестов стоит денег, фанатичное покрытие тестами может отдалить запуск проекта.
- Большую часть проблем с кодом можно решить еще до запуска тестов с помощью анализаторов кода (pylint, pep8). Интегрируйте эти инструменты в ваши редакторы (если ваш любимый редактор не позволяет их интегрировать, то вы скорее всего все еще плохой программист).
- Если все же тесты в проекте есть, то без continuous integration они мертвый груз. Запускайте тесты автоматом после каждого коммита и присылайте через jabber уведомление об их статусе.
Собственно, если ваша основная задача — это написание фреймворка или библиотеки, то перед выпуском стабильной версии тесты нужны. Если вы экспериментируете или делаете что-то одноразовое на основе чьих-то чужих фреймворков, то скорее всего пунктов о 100% покрытии тестами не будет даже в требованиях.
Но если все же научиться писать тесты, то это может приносить удовольствие. Вы будете знать, что ваш код не только написан, но еще и как-то работает.
blog comments powered by Disqus
Support
If you like my posts, please support me on Gittip
