Поддержу тему (с небольшим запозданием).

Я нахожу данное обсуждение полезным.
Хотя, пожалуй, придется признать, что холивара не получилось ; но оно и к лучшему.

Почему я вообще вспомнил TDD?
Да потому что пример уж больно хорош.

Давайте рассмотрим проблему последовательно:
В процессе "рефакторинга":

1. некий функционал потерян
2. тестов на потерянный функционал не существует
3. каких - либо превентивных указаний на то, что данный конкретный функционал будет потерян, нет

Что это значит?
Это значит, что автор даже не предполагал, что такой функционал существует и что его необходимо сохранить или сознательно от него отказаться с соответствующим документальным оформлением.

Почему?
Проблема ли это именно TDD?
Нет.
TDD здесь - это всего лишь конечная миля.

Это чистой воды проблема эффективности применения логики в разработке, это проблема многомерности и многоплановости мышления.
И в этом плане, упомянув TDD я как раз и хотел, чтобы мы пришли к вопросу о важности многомерной логики в разработке.
Вообще, мой опыт говорит о том, что логика без TDD дает результат лучше, чем TDD без логики.

Дима задал очень правильный вопрос в своем самом первом посте.
Цитата:

Мы знаем, что наш разум имеет пределы, в том числе и в количестве неких "регистров" и "операций", которыми мы можем одновременно оперировать.
Это не только в программировании, это вообще в жизни.
Значит, при определенных уровнях сложности, наше мышление будет давать сбой, либо требовать чрезмерных ресурсов для безошибочной работы.

Так вот, дальше как раз и хотелось бы задуматься, какой необходим подход к проектированию (и только потом уже к разработке), чтобы в первую очередь, разработка укладывалась в необходимые нормы сложности, позволяющие в каждом случае изменения некоего функционала охватывать логическим "взглядом" всю матрицу затрагиваемых связей.

Управление сложностью - это вопрос, которым надо заниматься, который интересно обсуждать.
И не только применительно к программированию.

Я с удовольствием читаю соседние темы про тестирование.
Впервые за несколько лет я вижу на форуме не только функциональные, но и весьма интересные обсуждения.
В общем-то, у нас давно полно тем, которые мы готовы сформулировать вполне профессионально.
И если, несмотря на нехватку времени, у нас доходят до этого руки - это надо отметить.


_{P.S.
Артур, твой код нам здесь попался на глаза совершенно случайно.
У меня нет цели анализировать именно твой код или именно твой стиль разработки.
Да, он не ложится нормально на мой шаблон разработки, мне с ним трудно работать.
Но без него у меня не появились бы вопросы (о совместимости стилей и шаблонов мышления, например), на которые я бы не стал искать ответы.
Мы же не ищем легких путей, не так ли?}

А я сейчас читаю Е-буки по Ruby on Rails (т.к. на данном форуме увидел ссылку на Redmin, понравилось, сейчас стал смотреть как оно работает). Там есть несколько очень интересных концепций, в частности - разработка изначально основывается на Паттерне MVC (Модель, представление, контроллер), еще интересная вещь использование соглашений. Т.е. если ты пишешь код в соответствии с соглашениями, то "конструктор", например scaffold, может за тебя сделать бОльшую часть шаблонного кода (создает таблицу, с именем контрола, заполняет ее указанными полями, создает Представления, для отображения, редактирования, удаления). Можно, конечно, и руками все это прописать... Относительно тестов - возможность использования тестов (папки, необходимые контроллеры) генерируется сразу при создании проекта. Очень любопытная концепция.