Итак с чего все начиналось в моем случае....
Это были не совсем далекие времена(года так 2.5 назад), когда мы "на коленке" проектировали LIMB 1.x и с помощью него пытались выполнять определенные задачи. Это были самые первые шаги серьезной разработки, хотя и код да и метафора были просто кошмарными(да, слышал бы я тогда себя), но мы были уперты в своем желании изобрести колесо. Мы тогда еще не применяли XP и полагали, что систему можно запланировать загодя, нарисовав кучу красивых диаграм и картинок на тему "как там все будет круто работать". Однако реальность была такова, что требования к системе менялись ежечасно и порой приходилось переворачивать с ног на голову тонны кода. Когда в очередной раз "ой, а чего-то не работает" случалось, обычно проводились довольно утомительные сессии с дебагером, за которыми следовали "quick'n'dirty fixes", которые в свою очередь не гарантировали, что не было сломано что-то еще....
Я сейчас даже вспомнить не могу, как наткнулся на SimpleTest. По-моему, в свое время это было довольно сильным buzz word на SitePoint и чисто интуитивно я зашел на
www.lastcraft.com.
В этом действительно было что-то такое, что должно было как-то помочь побороть хаос, и я принялся изучать... Но не хватало примеров реального использования, те примеры, что есть в документации по SimpleTest...э..несколько искуственны и далеки от жизни.
Примерно в это же время мы чудом наткнулись на cvs репозиторий WACT на SourceForge, тогда не было ни одного официального релиза и весь код был только в cvs. Я был поражен качеством кода, я им просто упивался! Но больше всего меня поразила методология разработки через тесты. Какие там были шикарные тесты по тем временам! Я для себя твердо решил в тот момент, что LIMB 2.x будет написан с использованием TDD. Как раз подоспел крупный заказ, который бы LIMB 1.x просто не потянул без очередной "революции" и мы с syfisher выкинули все UML долгосрочные диаграммы, попыталиь сделать пару карточек на неделю и сели в пару писать тесты(это был для нас первый XP опыт).
Мы насколько позволяли наши знания и опыт пытались вести разработку через тестирование, однако на 100% не получилось. Стоит признать, что TDD с "бухты барахты" применить не получится, требуется переворот мировоззрения разработчика(я пытаю судить по себе). Конечно, будет звучать громко, если я скажу, что учился программировать с нуля, вникая в азы TDD, но примерно так оно и было.
Мы применяли только модульные тесты и это было одной из ошибок(на тот момент пакета для web тестирования в SimpleTest не было). Мы все равно часто пользовались дебаггером для отлавливания GUI ошибок и многие вещи ошибочно считали слишком простыми, чтобы тестировать. Да и опыта ООП не хватало...я смотрю на прежний код и мне местами берет вдрожь(хотя это нормально, посмотрите свои лабораторные за первый курс
). Еще одной ошибкой было то, что когда было слишком сложно написать тест, мы сдавались(в основном это возникало из-за слишком сложных зависимостей в коде). Все это дало о себе знать впоследствии - LIMB 2.x подходит для средних проектов, но не для сложных, с богатой бизнес моделью....однако я благодарен этим ошибкам, т.к они позволили понять, каким именно должен быть код, чтобы его было легче протестировать.
Поставив testability основным приоритетом, мы начали разработку LIMB 3.x. Даже до беты еще далековато, однако в общем и целом я доволен качеством кода, в чем я премного благодарен TDD. Да, я и сейчас пользуюсь дебагарем, но только во время тестирования, когда первые реализации ведут себя непредсказуемо. Я почти не пользую дебагером для отловли ошибок в рабочем проекте, такое бывает оооочень редко. Крутые перцы типа Marcus Baker вообще не пользуются дебагером, это наверное будет следующая ступень развития
TDD учит правильно выделять небольшие тесно связанные ответственности в неповоротливых участках кода, т.к иначе тестирование превращается в муку. Для меня это одно из самых важных последствий TDD, и если кто-то упрекнет меня в code bloat после того, как из god-like класса я выделил бы шесть узкоспециализированных да еще и пару-тройку интерфейсов, и после этого читабельность и тестируемость системы повысились, я просто рассмеюсь.
Несколько слов о том, как с помощью TDD разрабатывается новый код. Так вот, TDD не придумает за вас имплементацию. TDD никак не заменяет творческий полет мысли. Это
всего лишь способ справиться с хаосом разработки, нельзя механически набивая тесты, создать нечто полезное. Однако я точно уверен, что TDD тренирует интуитивное мышление, как будущий код должен примерно выглядеть. Поверьте, вначале TDD пути порой очень трудно написать даже пару строчек кода тестов для еще несуществующей функциональности, однако терпенье и труд воздадутся сторицей.
Для меня наличие грамотных тестов - это признак профессионального подхода к разработке. Это как с cvs: или ввести в практику или даже не пытаться, т.к "...ну, это надо делать коммит".
Тут очень популярно говорить, ну зачем мне TDD, если проект маленький. Хорошо. У меня только один вопрос: вы для каждого проекта все кодируете с нуля? Нет никакой собственной библиотеки из проверенных временем решений? Если нет, то это самоубийство. А если да, то почему бы вашу библиотеку не зафиксировать тестами? Какая на этот раз отговорка?
"зачастую написание приложения с ипользованием тестов в два раза дороже и более, чем без тестов." - откуда такие цифры?
"Тесты не предоставляют механизма тестирования наледований большой вложености" - наследование в 99% хуже композиции, меня настораживает наследование более 3 уровней... Как насчет рефакторинга?
P.S. меня также интересует тема формализации TDD. Такое вообще возможно? Мне кажется TDD - чисто инженерная поделка, которая будет трудно поддаваться мало-мальскому формальному описанию.
P.P.S. Я надеюсь, вы не сочтете дешевым пиаром столь частое употребление слова LIMB в повествовании?
![[sid]](https://secure.gravatar.com/avatar/c51853b199f011af6ff7bfdc5973af53?s=96){kind=avatar}
hpUnit и пошёл тестировать. phpUnit предоставляет средстава для модульного тестирования. Единственный опыт, который я вынес из этого - проектирование интерфейсов "того как будет использовано" до собственно использования. Это меня сподвигло на поиски/эксперименты проектирования интерфейсов классов. Выгода от этой части опыта - минимальная - всё что я вынес - умение писать модульные тесты, куча перепробованных вариантов, сам дух TDD
народ у нас как-то это все сопоставит и примет правильное решение.. какое бы оно ни было