Здравствуйте, abibok, Вы писали:

N>>То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации).
A>Это не так, а как раз наоборот. Юнит тесты особенно хорошо показывают свою ценность именно в условиях постоянных доработок проекта и изменения требований, потому что дают уверенность в качестве кода и делают рефакторинг простой и быстрой задачей.

Я говорил про TDD, а Вы начали про юнит-тесты в целом. Вы не замечаете подмены тезиса со своей стороны?

N>>В более типичном случае всегда есть места, которые переделываются по 2-3 раза, включая внутренние интерфейсы, код пишется раньше тестов для того, чтобы проверить, что он в принципе работает, и уже после получения работающего результата возникает понимание, что надо было делать и почему именно так. В этом случае TDD в принципе непригоден.
A>Вы путаете TDD с бардаком,

Нет, не путаю. Читайте внимательно. Я, наоборот, говорил, что для эффективного применения TDD необходимым условием является высококачественное планирование, умный заказчик, который знает, чего хочет, изначально правильная архитектурная разработка (что может определиться только постфактум) и, возможно, другие столь же нетипичные условия. В более реальных условиях он перестаёт работать, и от него остаются только лулзы для менеджера.

A> когда нет планирования и постоянного feedback от заказчика,

А даже если планирование есть, чем оно поможет, если заказчик изменил требования?

A> либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту.

О да. Это не царь-батюшка плохой, это бояре его волю переврали.

N>>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся.
A>На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали".

Хм. Кто-то говорил только что о правильном планировании и взаимодействии с заказчиком, а теперь рассказывает про то, что показал что-то через год?

N>>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!")
A>Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?

Самое прямое. Юнит-тест — это функциональный тест для компоненты нижнего уровня (функции, класса). Показало результат — это показало соответствие кода ожиданиям этого теста.
Если Вы решили прочесть "показало результат" как "показало заказчику результат" (или хотя бы приёмке верхнего уровня), то это чисто Ваши домыслы, для которых нет основания в моих словах.

N>>Второй — это хоть какая-то надёжность работы самого теста.
A>Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.

То, что Вы говорите — расхожий миф, исходящий из авторов красивых книг и не имеющий никакого отношения к реальности. Да, написать тест, который зовёт функцию и проверяет результат — это гарантированный способ сломать тест, пока функции ещё нет. Но если тест, например, проверяет, что функция вообще что-то вернула, но игнорирует её значение, то он окажется удовлетворённым при любой реализации функции. Если реализатор работает честно, то он такого не сделает. Но если нет, то он тривиально подсунет фактическую непроверку результата (а при достаточном навыке и замаскировав отсутствие проверки). Значит, всё равно нужно ревью кода. А если делается ревью, то ревьюер и способен проверить как наличие тестов, так и их реальное выполнение. А бесконтрольное соответствие принципу "сначала тест, потом код" без оценки качества кода и теста — ничего не даёт, кроме уже описанного мной ранее средства самоорганизации (тест является видимой и описанной целью, требующей удовлетворения).

N>>Первое я ещё могу принять как обоснование, второе — нет, потому что неизвестно качество самого теста: например, он может проверять, что функция вообще реализована, но соглашаться на любое возвращённое значение, независимо от его корректности.
A>Если тест стал настолько сложным, что в нем легко допустить такую ошибку,

Такую ошибку или намеренную диверсию возможно допустить независимо от сложности теста.

A> значит либо это не юнит-тест, а функциональный тест,

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

A> либо пора думать о тестах для тестов, т.е. о создании упрощенной модели тестируемого продукта, на которой можно отлаживать тесты.

В следующем комментарии я как раз и рассказывал про тесты для тестов, но без модели тестируемого.

N>>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами.
A>TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD.

Во-первых, не вижу обоснования этому тезису (что она сложнее). Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще.

A> Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются.

С какой ветряной мельницей Вы спорили на этот раз?

N>>Мы для обеспечения корректности тестов используем инверсии тестов. Инверсия — это запуск при специальном входном условии (параметре) самого теста, которое требует выполнить изменение входных данных проверяемого кода с тем, чтобы результат не соответствовал ожидаемому без инверсии. Например, если проверяется сложение строк, на входе 2 строки по 40 символов, а на выходе 80, то инверсией может быть задание пустой строки вместо второй. (В реальности примеры сильно сложнее: например, один из тестов — порвать связь с объектом и проверить, что первая тревога уровня warning прошла в интервале от 9 до 15 секунд; тогда инверсия — не рвать связь.) Тест корректен, если он выполняется положительно без инверсий со всеми вариациями и отрицательно — при любой из инверсий. Проверки, список вариаций и инверсий входят в спецификацию теста и соответствие им проверяется через явное ревью кода теста.

A>Это — не юнит-тесты.

Ну и что с того? Я не вижу причины ограничивать рассмотрение этих механизмов тестами минимальных компонент.

N>>>То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации).
A>>Это не так, а как раз наоборот. Юнит тесты особенно хорошо показывают свою ценность именно в условиях постоянных доработок проекта и изменения требований, потому что дают уверенность в качестве кода и делают рефакторинг простой и быстрой задачей.

N>Я говорил про TDD, а Вы начали про юнит-тесты в целом. Вы не замечаете подмены тезиса со своей стороны?

Хорошо, у вас был опыт применения TDD на реальном проекте? С какими трудностями столкнулись? Почему считаете, что TDD не работает? Я стал говорить о юнит-тестах, потому что это один из ключевых компонентов TDD. В данном случае в моей фразе все слова "юнит тесты" можно заменить на "TDD", от этого смысл не изменится, просто постановка вопроса станет более общей. Если хотите еще шире, то замените "TDD" на "XP".

N>Я, наоборот, говорил, что для эффективного применения TDD необходимым условием является высококачественное планирование,

Да, но не в привычном waterfall стиле.

N>умный заказчик, который знает, чего хочет

Это не обязательно. Большинство заказчиков не способны четко и исчерпывающе сформулировать ТЗ в начале проекта. TDD как раз помогает работать с такими реальными заказчиками.

N>изначально правильная архитектурная разработка (что может определиться только постфактум)

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

N>В более реальных условиях он перестаёт работать, и от него остаются только лулзы для менеджера.

Если менеджер не имеет опыта применения TDD, но с горящими глазами бросился внедрять новую игрушку, прочитав пару статей на тему, то да — игрушкой и останется. В противном случае, да еще и в условиях высокой дисциплины разработки в команде, TDD не то что хорошо работает, а даже я бы сказал является незаменимой техникой. Как нельзя программировать без классов, так нельзя делать проекты без TDD.

N>А даже если планирование есть, чем оно поможет, если заказчик изменил требования?

Если планирование есть, то проект может получиться, а может провалиться. А вот если планирования нет, то начиная с определенного уровня сложности проект обречен на провал. Планирование само себе не гарантирует успеха, но является его необходимым требованием. У нас говорят "Failing to plan is planning to fail" и я сам не раз убеждался, что скорость кодирования или индивидуальное мастерство программистов стоят далеко не на первом месте и важны куда менее, чем грамотное планирование и хороший communication.

A>> либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту.
N>О да. Это не царь-батюшка плохой, это бояре его волю переврали.

При чем здесь царь и бояре? TDD — достаточно сложная и имеющая массу нюансов при практическом применении техника. Если вы вдруг решили написать сотню тестов в готовом проекте, то это что угодно, кроме TDD.

N>>>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся.
A>>На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали".

N>Хм. Кто-то говорил только что о правильном планировании и взаимодействии с заказчиком, а теперь рассказывает про то, что показал что-то через год?

Читайте внимательно. "Показали через год" — это негативный пример, который показывает как делать не надо. TDD здесь и не пахнет, даже если разработчики пытались писать какие-то тесты.

N>>>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!")
A>>Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?

N>Самое прямое. Юнит-тест — это функциональный тест для компоненты нижнего уровня (функции, класса). Показало результат — это показало соответствие кода ожиданиям этого теста.

Простите, но у вас каша в голове. Начиная с того, что тестеры не занимаются написанием и выполнением юнит-тестов и заканчивая смешивание понятий функционального и юнит тестов. То что в проекте успешно проходят юнит тесты абсолютно ничего не говорит о пригодности проекта к релизу или даже к способности проекта выполнять хотя бы какой-то полезный для заказчика функционал. "Проходимость" юнит-тестов — это, пожалуй, наименее информативная из всех метрик. Можете повесить на стенку мраморную табличку, где будет выбита прямая линия и написано "Pass — 100%". Эта табличка будет актуальна для любого проекта на многие годы просто потому что такова природа юнит-тестов, они всегда проходят на 100%.

N>>>Второй — это хоть какая-то надёжность работы самого теста.
A>>Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.

N>То, что Вы говорите — расхожий миф, исходящий из авторов красивых книг и не имеющий никакого отношения к реальности.

Расскажите как обстоят дела в вашей реальности.

N>Да, написать тест, который зовёт функцию и проверяет результат — это гарантированный способ сломать тест, пока функции ещё нет. Но если тест, например, проверяет, что функция вообще что-то вернула, но игнорирует её значение, то он окажется удовлетворённым при любой реализации функции.

Тест должен сначала не пройти, а потом, после реализации функции или исправлении бага — пройти. Принципиальное значение имеет факт такого перехода от fail к pass, а не просто "всегда fail" или "всегда pass".

N>Если реализатор работает честно, то он такого не сделает. Но если нет, то он тривиально подсунет фактическую непроверку результата (а при достаточном навыке и замаскировав отсутствие проверки). Значит, всё равно нужно ревью кода.

TDD не гарантирует отсутствия ошибок в юнит-тестах. Такое вполне себе встречается, юнит-тесты — это такой же код и пишут его те же несовершенные люди. Как и любой код, юнит-тесты требуют code review при первом сабмите и позже при любых изменениях.

N>А бесконтрольное соответствие принципу "сначала тест, потом код" без оценки качества кода и теста — ничего не даёт

С чего вы взяли что такой подход будет называться TDD? Кто сказал, что написание тестов позволит обходиться без оценки качества?

N>кроме уже описанного мной ранее средства самоорганизации (тест является видимой и описанной целью, требующей удовлетворения).

Маленькие дети, когда не хотят делать уроки, начинают раскладывать на столе тетрадки, точить карандаши и прочими способами имитировать бурную деятельность. Лишь бы не работать. Так и здесь, если вам необходимо нечто, о чем можно отчитаться начальству как о внедрении и средстве самоорганизации — ок, но не говорите потом что TDD не работает, потому что такое применение — это не TDD.

N>>>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами.
A>>TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD.
N>Во-первых, не вижу обоснования этому тезису (что она сложнее).

Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше.

N>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще.

Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами."

A>> Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются.
N>С какой ветряной мельницей Вы спорили на этот раз?

Да с вами же. С вашей позицией "в реальной жизни TDD не работает". Мои слова подкреплены реальным успешным опытом, а ваши? Ну если не считать экспериментальных попыток "попробовали что-то такое, ничего не получилось, ну и хрен с ним, некогда разбираться — работать надо".

Здравствуйте, abibok, Вы писали:

N>>Я говорил про TDD, а Вы начали про юнит-тесты в целом. Вы не замечаете подмены тезиса со своей стороны?
A>Хорошо, у вас был опыт применения TDD на реальном проекте? С какими трудностями столкнулись? Почему считаете, что TDD не работает?

Потому что обнаружилось следующее:
1. Формальное прохождение заранее рассчитанных тестов недостаточно для проверки адекватности реализации. Особенно это проявляется в том, что является неизбежной спецификой реализации, но не оказалось заранее рассчитано на момент проектирования уровня (когда фиксируется состав тестов).
2. Проверка теста по принципу "вначале не работал, теперь работает" некорректна в принципе, и наблюдались случаи, когда проверка оказывалась некорректной по реализации, но это не могло быть распознано.
3. Метод "сначала свалимся" не работает как минимум в случае изменения самих тестов — например, в случае обновления тестирующей подложки.

A> Я стал говорить о юнит-тестах, потому что это один из ключевых компонентов TDD. В данном случае в моей фразе все слова "юнит тесты" можно заменить на "TDD", от этого смысл не изменится, просто постановка вопроса станет более общей. Если хотите еще шире, то замените "TDD" на "XP".

Я не хочу делать ни первую замену, ни вторую, потому что они обе некорректны. Юнит-тесты существуют отдельно от TDD, а XP — значительно более обширное понятие.

N>>Я, наоборот, говорил, что для эффективного применения TDD необходимым условием является высококачественное планирование,
A>Да, но не в привычном waterfall стиле.

Спасибо, кэп.

N>>умный заказчик, который знает, чего хочет
A>Это не обязательно. Большинство заказчиков не способны четко и исчерпывающе сформулировать ТЗ в начале проекта. TDD как раз помогает работать с такими реальными заказчиками.

Вот тут XP — возможно, помогает (по крайней мере, если заказчик начинает нести чушь, можно это опознать пораньше), а при чём тут TDD?

N>>изначально правильная архитектурная разработка (что может определиться только постфактум)
A>Это тоже не обязательно. TDD позволяет изменять архитектуру в процессе работы, не боясь что проект станет нестабильным и все начнет сыпаться.

Только вот он на этом этапе удваивает работу — когда ты даже прототип не можешь нарисовать без тестов.

N>>В более реальных условиях он перестаёт работать, и от него остаются только лулзы для менеджера.
A>Если менеджер не имеет опыта применения TDD, но с горящими глазами бросился внедрять новую игрушку, прочитав пару статей на тему, то да — игрушкой и останется. В противном случае, да еще и в условиях высокой дисциплины разработки в команде, TDD не то что хорошо работает, а даже я бы сказал является незаменимой техникой. Как нельзя программировать без классов, так нельзя делать проекты без TDD.

С высокой дисциплиной разработки в команде TDD ничего не меняет. Написаны тесты до кода или после, тесты всё равно адекватны и без прохождения тестов код не будет сдан как сделанный. А вот с плохой дисциплиной и исполнением на тяп-ляп он является средством замаскировать проблемы (как же, тесты есть — а их адекватность никого не волнует).

N>>А даже если планирование есть, чем оно поможет, если заказчик изменил требования?
A>Если планирование есть, то проект может получиться, а может провалиться. А вот если планирования нет, то начиная с определенного уровня сложности проект обречен на провал. Планирование само себе не гарантирует успеха, но является его необходимым требованием. У нас говорят "Failing to plan is planning to fail" и я сам не раз убеждался, что скорость кодирования или индивидуальное мастерство программистов стоят далеко не на первом месте и важны куда менее, чем грамотное планирование и хороший communication.

A>>> либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту.
N>>О да. Это не царь-батюшка плохой, это бояре его волю переврали.
A>При чем здесь царь и бояре? TDD — достаточно сложная и имеющая массу нюансов при практическом применении техника. Если вы вдруг решили написать сотню тестов в готовом проекте, то это что угодно, кроме TDD.

N>>>>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся.
A>>>На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали".

N>>Хм. Кто-то говорил только что о правильном планировании и взаимодействии с заказчиком, а теперь рассказывает про то, что показал что-то через год?

A>Читайте внимательно. "Показали через год" — это негативный пример, который показывает как делать не надо. TDD здесь и не пахнет, даже если разработчики пытались писать какие-то тесты.

N>>>>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!")
A>>>Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?

N>>Самое прямое. Юнит-тест — это функциональный тест для компоненты нижнего уровня (функции, класса). Показало результат — это показало соответствие кода ожиданиям этого теста.

A>Простите, но у вас каша в голове.

Судя по Вашему дальнейшему рассказу и тому, чему именно Вы тут возражаете, эта каша существует чисто в Вашем воображении. Что Вы туда намешали — я даже боюсь предположить.

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

Потрясающе. Сначала Вы зачем-то вспомнили тестеров, хотя я про них ни слова не сказал. Далее приписали заведомо некорректный и непонятно откуда взявшийся вывод и успешно его опровергли. Так держать!

A> "Проходимость" юнит-тестов — это, пожалуй, наименее информативная из всех метрик. Можете повесить на стенку мраморную табличку, где будет выбита прямая линия и написано "Pass — 100%". Эта табличка будет актуальна для любого проекта на многие годы просто потому что такова природа юнит-тестов, они всегда проходят на 100%.

Вы тут заговариваетесь и опровергаете сам себя. Тут "всегда проходят", а перед этим "если проходят"...
Я уже боюсь предполагать, что Вы мне припишете в следующий раз.

N>>>>Второй — это хоть какая-то надёжность работы самого теста.
A>>>Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.

N>>То, что Вы говорите — расхожий миф, исходящий из авторов красивых книг и не имеющий никакого отношения к реальности.
A>Расскажите как обстоят дела в вашей реальности.

А я это тут всё время и рассказываю.

N>>Да, написать тест, который зовёт функцию и проверяет результат — это гарантированный способ сломать тест, пока функции ещё нет. Но если тест, например, проверяет, что функция вообще что-то вернула, но игнорирует её значение, то он окажется удовлетворённым при любой реализации функции.
A>Тест должен сначала не пройти, а потом, после реализации функции или исправлении бага — пройти. Принципиальное значение имеет факт такого перехода от fail к pass, а не просто "всегда fail" или "всегда pass".

Принципиальное значение для кода, который должен жить, а не один раз быть сданным и всё, является то, что всегда можно проверить, причём автоматизированно, что он fail, когда реализация нарушена. Однократная проверка вначале — это не проверка, тест мог начать работать чисто случайно.

N>>А бесконтрольное соответствие принципу "сначала тест, потом код" без оценки качества кода и теста — ничего не даёт
A>С чего вы взяли что такой подход будет называться TDD? Кто сказал, что написание тестов позволит обходиться без оценки качества?

С того, что формальное определение TDD ничего не говорит про оценку качества, а при работающем административном обеспечении качества основные подходы TDD теряют значимость. Остаётся промежуточный случай — когда менеджер хочет обеспечить качество, но не знает, как. И вот в этом случае ему может помочь TDD (а может и не помочь, если исполнители обучились махлевать).

N>>кроме уже описанного мной ранее средства самоорганизации (тест является видимой и описанной целью, требующей удовлетворения).
A>Маленькие дети, когда не хотят делать уроки, начинают раскладывать на столе тетрадки, точить карандаши и прочими способами имитировать бурную деятельность. Лишь бы не работать. Так и здесь, если вам необходимо нечто, о чем можно отчитаться начальству как о внедрении и средстве самоорганизации — ок, но не говорите потом что TDD не работает, потому что такое применение — это не TDD.

Нет, мне такое не нужно.

N>>>>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами.
A>>>TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD.
N>>Во-первых, не вижу обоснования этому тезису (что она сложнее).
A>Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше.

Моя практика ничего подобного не показывает. Интересно, какие у вас задачи и как вы именно решаете, что от отсутствия предварительного написания тестов код размножается в 2-3 раза? Не могу себе представить механизм для этого.

N>>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще.
A>Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами."

Тогда непонятен общий характер возражения. Я как раз говорю, что TDD не улучшает разработку.

A>>> Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются.
N>>С какой ветряной мельницей Вы спорили на этот раз?
A>Да с вами же. С вашей позицией "в реальной жизни TDD не работает". Мои слова подкреплены реальным успешным опытом, а ваши? Ну если не считать экспериментальных попыток "попробовали что-то такое, ничего не получилось, ну и хрен с ним, некогда разбираться — работать надо".

Ваши слова будут подкреплены реальным успешным опытом, когда будет сравнение двух очень сходных по сути разработок (а лучше вообще идентичных) со сходными исполнителями, но в одном случае с чётким следованием TDD, а в другом — без. И даже не так, а на массиве проб, среди которых и идеальные исполнители, и бардачные до предела. А на сейчас Ваша позиция ничем не отличается от "95% заболевших проказой ели свежие огурцы => огурцы вызывают проказу", потому что Вы не в состоянии отделить без массива проб влияние TDD и влияние таких факторов, как общее качество организации проекта и административной работы, уровень и методы работы исполнителей, и так далее. Пока что Вы говорите только о своих (или начальника) хороших организационных способностях.
А вот для опровержения общности вывода достаточно одного контрпримера, и я такие контрпримеры здесь и в соседних тредах приводил.

N>Потрясающе. Сначала Вы зачем-то вспомнили тестеров, хотя я про них ни слова не сказал. Далее приписали заведомо некорректный и непонятно откуда взявшийся вывод и успешно его опровергли. Так держать!

Вот ваши слова: "чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!"

A>>Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше.
N>Моя практика ничего подобного не показывает. Интересно, какие у вас задачи и как вы именно решаете, что от отсутствия предварительного написания тестов код размножается в 2-3 раза? Не могу себе представить механизм для этого.

Объем тестов может превышать объем product code в 2-3 раза. Если тесты не писать, то поддерживать этот дополнительный объем не нужно.

N>>>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще.
A>>Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами."
N>Тогда непонятен общий характер возражения. Я как раз говорю, что TDD не улучшает разработку.

Facepalm. Ну как еще объяснить, если вы не помните что сами же писали строчкой выше и в одном и том же абзаце опровергаете сами себя?

Здравствуйте, abibok, Вы писали:

A>Вот ваши слова: "чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!"

Ооо, так Вы начали читать, на что возражаете. Шарман, шарман. Да, каюсь: такого подвига я не ожидал и не подключил контекст предыдущих (до Вас) разговоров в этом треде. Но Вы начали свои возражения, отвергнув всё, что было написано до того, по принципу "Командир сказал: хорёк!", так что такое ограничение контекста было естественно. А теперь, оказывается, есть и суслики. В таком случае, сообщаю, что я принципиально отказываюсь обсуждать поднятые вопросы в предлагаемом Вами стиле "у меня всё работает, а у кого нет — пусть лечится". Я привёл в этом треде кучу технических возражений против основных подходов TDD, составляющих его принципиальную основу. Если Вы не согласны — пожалуйста, или опровергните хотя бы часть их, именно как технические возражения, или опишите, что именно и как Вы понимаете под TDD (и почему взяты именно такие определения и понимания) и как в таком случае оно образует цельный и непротиворечивый подход. Особенно меня интересует столкновение с реальным миром, который или вообще не agile, или agile, но не такое. Например, если мы берём и дорабатываем чужую библиотеку (стандартный случай работы с legacy кодом), выживет ли Ваш подход в этом случае.

A>>>Сложнее, потому что приходится писать, проверять и поддерживать в рабочем состоянии больше кода. Нередко в 2-3 раза больше.
N>>Моя практика ничего подобного не показывает. Интересно, какие у вас задачи и как вы именно решаете, что от отсутствия предварительного написания тестов код размножается в 2-3 раза? Не могу себе представить механизм для этого.

A>Объем тестов может превышать объем product code в 2-3 раза. Если тесты не писать, то поддерживать этот дополнительный объем не нужно.

Ага, понял. Пишете Вы как-то странно, логика плохо ловится. Тогда встречный вопрос: почему Вы считаете, что эта ситуация — какая-то специфика TDD? Наличие кода тестов — неотъемлемое свойство именно автоматизированных тестов, и это неизбежность. Это цена, которую надо платить за автоматизацию. Почему такой акцент именно на TDD?

N>>>>Во-вторых, кому Вы возражаете? Я не говорил, что она с ним проще.
A>>>Я возражаю вашим словам строчкой выше — "TDD этого ... в общем случае не требует, а косвенно, наоборот, обещает ..., что code review при TDD нужен меньше — потому что всё покрыто тестами."
N>>Тогда непонятен общий характер возражения. Я как раз говорю, что TDD не улучшает разработку.

A>Facepalm. Ну как еще объяснить, если вы не помните что сами же писали строчкой выше и в одном и том же абзаце опровергаете сами себя?

Вы в состоянии отличить чьи-то (в данном случае TDD) обещания и реальное выполнение? Судя по этому комментарию, нет.

(Ну тогда продолжайте голосовать за Путина/Януковича/Обаму/etc., это точно Ваш кандидат.)