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

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

Published

20 September 2012

In tags we trust

Fork me on GitHub