Согласен, всё зависит от проекта и от заказчика.
Может оказаться, что половина функционала вообще не нужна, ну то есть была нужна на момент разработки, но потом потеряла актуальность.
Хм, получается вы берете код, смотрите что он делает, меняете его структуру, возможно где-то алгоритмы и логику так, чтобы в конце-концов получить такой же функционал. Этот процесс называется рефакторинг без TDD.
Его можно проводить поэтапно, модуль за модулем, а можно раз и сразу на всю систему.
Просто второй вариант часто бывает слишком долгим, заказчики часто не готовы столько ждать, особенно, когда им срочно потребовалось «добавить пару кнопочек».
Это может кончиться руганью с заказчиком из-за того, почему так долго, либо поддержкой старого кода, пока не внедрили новый. ИХМО, и то, и то плохо.
Ах да, ещё бывает так, что моки подпихнуть не представляется возможным.
В итоге, один и тот же код многократно запускается в каждом тесте, и при поломке этого кода ломаются все эти тесты.
Банальный пример, сломался у вас логгер. Отвалились все модули, которые что-нибудь пишут в лог.
Это в корне ломает половину идей TDD и тоже ведет к хрупким тестам.
Тут спорный вопрос, все зависит от кода. Точнее от связей внутри.
По идее, надо чтобы каждый модуль был как можно более автономным, а количество связей минимально, но быдлокодеры об этом не знают, поэтому получается один большой кусок кода.
И ещё, есть такой antiparten — хрупкие тесты.
На практике бывает так:
1. выделяем модуль, на все связи пишем моки, связей дофига, поэтому моки иногда длиннее самого проверяемого кода
2. пишем тесты, поскольку связей дофига, то тестов тоже дофига, на каждую ситуацию
3. один модуль протестирован, убито дофига времени, осталось ещё 100, а то и 200 (реальная ситуация).
4. меняем пару строчек логики, отваливается штук 20 тестов, уходим ещё на 4 часа в отладку и починку этих тестов
Итог,
— программист делает кучу тупой и тяжелой работы,
— эта работа бесполезна, т.к. любое изменение в коде ломает чуть ли не половину тестов, тесты не учитывают все варианты, то есть баги ещё остались.
— программист (даже очень хороший) искренне думает, что TDD — это какая-то идеализированная штука, которую не реально применить в реальном проекте.
Кончается всё тем, что после долгих мучений все дружно забивают на тесты.
Когда проводите рефакторинг, на новый код нужно писать Unit-тесты. А то что ничего не сломалось,
просто поймите, TDD — это лакмусовая бумажка хорошей архитектуры приложения, если всё клево, то тесты писать легко и приятно, а если быдло-код, то тесты нормальные написать практически не возможно, а с ненормальными — умучаетесь. Решение проблемы, либо отказаться от unit-тестов на старый код и проверять его качество как-то ещё, либо всё перерефакторить (что в данной ситуации чуть быстрее чем переписать с нуля, но всё-равно тоже долно).
Doctrine 1.2 так же реализует патерн ActiveRecord
Doctrine 2.2 — реализует объектную модель. Это может быть полезно, если у вас в объектах дофига логики, и не вся она попадает в БД.
Симпатично. удобно кликать, удобно смотреть. А за идею блокировать некоторые домены — вообще памятник поставить можно. Очень понравилось.
Спасибо большое.
> — это скорее всего случайно поставленный символ где-нибудь в условии в шаблоне.
мне одни товарищи на некоторых запросах вообще, то кавычку, то скобку, то php-код вываливали.
попадаются такие товарищи, которые пишут(правят) код ни разу его не запуская.
я бы тоже посоветовал redmine.
он гибок(благодаря тому, что он написан на RubyOnRails), имеет кучу плагинов.
плагинов море, но их нужно уметь выбирать, некоторые написаны криво или не эффективно при использовании под нагрузкой
Если чего-нибудь в этой системе ещё хочется, то можно сделать свой плагин или воспользоваться REST протоколом.
