Буду первым.
Холиварить не хочу.
С краткой теорией TDD знаком. Против нее ничего не имею.

Но хотельсь бы услышать коментарии специалистов по такому моменту:
Есть некая Программа обладающая по мнению Программиста1 функциями A и B.
Программист1 покрывает эти функции тестами. Ок.
Программист1 решил внести функцию C. Соответственно подготовил тест, реализовал C. Прошел тесты для A, B и C.
Все вроде бы хорошо, но Программист1 не учел (потому что не знал), что Программа обладает еще и
функцией D, которая поломалась из-за C.
С точки зрения теории TDD, кмк, этого бы не произошло если бы Программист1 писал Программу начиная с ХелоуВорд.
Но в нашем примере это не так - был еще и Программист0.
Как избежать подобных проблем? Какие есть теории?
Стоит ли вообще полагаться на тесты?
Стоит ли большую часть времени разработки тратить на разработку теста, если вдруг окажется что тесты врут?
Или может нужно смотреть гораздо шире тестов и пытаться разумом и/или интуицией охватить последствия внесения функции C ?

vandalsvq писал(а) 05. Мая 2010 :: 12:40:
эээ... в хорошем или плохом смысле?

berezdetsky писал(а) 05. Мая 2010 :: 13:06:
Возможно и ошибаюсь. Но из краткого изложения теории я сделал такой вывод.

trad

Собственно, я оспаривал само утверждение, а не точку зрения теории на него. Если теория TDD так утверждает - это (холивара ради) проблемы теории.  

Т.е. если существует ошибка, тестировать которую Программисту1 просто не придёт в голову - соответствующий тест не будет написан. Возьмём недавний пример - artbear не мог представить себе, что кто-то предпочтёт штатные конструкторы 1С конструкторам 1С++. И даже не считает это ошибкой - тесты ведь проходят..  

Добавлено: если чё, я не против TDD. Хуже от него точно не будет. 

berezdetsky писал(а) 05. Мая 2010 :: 13:47:
в том утверждении и была точка зрения теории.

fez
Вот, а из "довольно большого количества практик" у нас применяется только "коллективное владение кодом" (и оно, кстати, хорошо помогает в разборе полетов и нахождении крайнего) и поэтому TDD тут, наверное, не особо помогает.

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

trad писал(а) 05. Мая 2010 :: 14:24:

В разборе полетов TDD действительно не помогает, ибо направлено на уменьшение количества тех самых полетов

Цитата:

Подпишусь под каждым словом.

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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