Вопросы по TDD

Lightning

Трудоголик
Вопросы по TDD

Три недели как пытаюсь освоить TDD. Использую SimpleTest.
Возникло несколько моментов, в которых я сомневаюсь. У меня в архитектуре проекта применяется MVC, причем на основании URL выбирается и создается контроллер, а дальше он (в зависимости от запроса, данных из конфига и т.д.) выбирает и создает view и объекты модели. Тестирование View-ов и Model-ей не представляет проблемы, но тестирование контроллеров вызывает трудности, т.к. у меня контроллеры сами порождают объекты.

Что делаю я:

1. Выношу создание View-ов и Model-ей в отдельные методы контроллеров.
2. Генерирую классы моков для View-ов и Model-ей.
3. Создаю моки View-ов и Model-ей. С помощью методов expectArguments() и expectArgumentsAt() задаю данные, которые они должны принять от контроллера.
4. Создаю частичный мок контроллера, в котором перекрываю методы, создающие View-вы и Model-и, с помощью setReturnValue() делаю так, чтобы они возвращали моки.
5. Запускаю частичный мок контроллера, передаю в него тестовые данные и т.д
6. Вызываю методы tally() моков.

Лично мне мой способ не нравится, т.к. тесты получаются сложные и довольно большие. Написать такой тест сразу без ошибок не всегда получается. В результате получается, что нужно параллельно отлаживать тест и класс. Кроме того, вынесение создание объектов в отдельные методы создает лишнюю косвенность, ненужную в данном случае.
Что вы думаете/посоветуете?
 

zerkms

TDD infected
Команда форума
контроллеры, имхо, это уже тот уровень, когда модульные тесты должны быть заменены на функциональные. сам ведь видишь - насколько полученные тесты получаются сложными и хрупкими.
 

Lightning

Трудоголик
сам ведь видишь - насколько полученные тесты получаются сложными и хрупкими.
Вижу. Получается полная колбаса.
модульные тесты должны быть заменены на функциональные
Попробую. Хотя хорошие функциональные тесты у меня пока писать не получается. Был случай, что функциональные тесты все зеленые, а сам захожу: все нормально, только в одном месте warning вылез ))) Да кроме того, у меня там JS-а с AJAX-ом много, я пока еще не знаю как некоторые вещи протестировать.
 

zerkms

TDD infected
Команда форума
у нас исторически выработалась практика, что тестируются только "системные" вещи. а контроллер это уже клиентский код, который использует оттестированный системный.
 

pilot911

Новичок
не мог бы кто-нибудь использующий TDD привести пару-тройку аргументов в пользу этих тестов ?

как по мне, они просто отнимают время, не более того
 

zerkms

TDD infected
Команда форума
pilot911
хехе :) типичное заблуждение. плюшки навскидку:

1. набор готовых автоматических тестов: после того, как через месяц ты полезешь добавлять функционал в класс - его работоспособность будет подтверждена сразу же за пару секунд запуском тестов, а не тыканьем на все кнопки интерфейса с вводом всех возможных комбинаций аргументов. кстати именно этот пункт обычно причисляют к "замедляет разработку". но обычно оппоненты забывают, что в итоге так и так используемый код тестируется вручную! на живом проекте, а не в специально организованном тестовом окружении, разработчики вызывают функцию с разными аргументами, или отправляют форму с разными значениями. и в идеале это нужно проделывать после каждой из модификаций - нельзя утверждать на что модификации повлияли. т.е. время на тестирование, о котором, почему-то, всегда "забывают, получается куда больше, чем на написание и запуск теста.

2. документация: чтобы новому члену команды узнать, как работать с классом - достаточно открыть тесты и найти похожий вариант использования.

3. проектирование: ТДД вынуждает писать слабозависимый простой код. в противном случае тесты будет писать сложно, они будут хрупкими (см. ТС пост).

капля дёгтя:
практика довольно сложная, вхождение происходит довольно сложно, особенно когда нет багажа академических знаний (а их нет - потому как иначе не задавался бы вопрос) и когда под рукой нет более-менее опытного практика, который помог бы избежать ошибок новичка тдд. также - стоит подготовиться к тому, что на первых порах (несколько недель, может больше) дело будет идти субъективно (объективно, в зависимости от скиллов) медленнее, а написанный код и тесты почти наверняка будут сейчас или чуть позже выкинуты в корзину.

аминь! :)
 

pilot911

Новичок
Автор оригинала: zerkms
pilot911
убедительно? :)
да, конечно, особенно полезно для коллектива разработчиков - один сделал, уволился. следующий пришедший точно сможет проверить правильность своих фич
 

Lightning

Трудоголик
практика довольно сложная, вхождение происходит довольно сложно,
Да. Сложно перестроиться, непривычно, что кроме кода программы нужно еще поддерживать код тестов. Непривычно, что сначала нужно писать тесты, а потом код. Иногда на написание теста у меня уходит больше времени, чем на код, который он тестирует ))) В такие моменты самое сложное не "сорваться" и не начать писать код без тестов.
когда под рукой нет более-менее опытного практика
Нету, к сожалению.
на первых порах (несколько недель, может больше) дело будет идти субъективно (объективно, в зависимости от скиллов) медленнее
К сожалению, у меня пока так и получается, работа замедлилась. Пока что, единственным плюсом, который я получаю от TDD, является увеличение уверенности в работоспособности кода и отсутствие процесса отладки в обычной кошмарной форме.
а написанный код и тесты почти наверняка будут сейчас или чуть позже выкинуты в корзину.
Код врядли в корзину пойдет, а вот тестов уже достаточно туда пошло. Вот недавно туда пошли еще и модульные тесты контроллеров :)

-~{}~ 22.03.09 22:33:

Вот еще вопрос по теме.
Хочу использовать в проекте свои старые наработки на JavaScript, но для этого их код нужно модифицировать. Раз этот проект у меня в рамках TDD, то я хочу и модификацию сделать в рамках TDD. Каким образом это можно сделать? Написать модульные тесты для всего кода, который был разработан без тестов это, имхо, нереально. Или написать лишь функциональные тесты?

-~{}~ 22.03.09 22:34:

Как вообще можно перевести готовый код на TDD?
 

zerkms

TDD infected
Команда форума
Как вообще можно перевести готовый код на TDD?
покрывать тестами по мере необходимости - во время модификаций кода, непосредственно до.
 
Сверху