А вы используете TDD в своих проектах?

Замечательно. Так в чем вы видите проблему при использовании TDD? Короткие циклы разбиваете еще на более мелкие стадии, каждую начинаете с теста на то, что собираетесь сделать.

Собственно, суть такова:

• начинаем с написания теста, который пишется в объеме, необходимом и достаточном для того, чтобы тест не проходил
• новый код пишется после того, как будет написан тест, который не проходит
• новый код пишется только в том объеме, который достаточен для прохождения теста

Все остальное - уже менее важно.

Может проще написать на листочке - хочу то, то и то, потом сесть и написать код, провести приемочное тестирование и готово.

новый код пишется только в том объеме, который достаточен для прохождения теста

Вот меня в TDD вечно смущает вот эта часть. Звучит как «пишите любой говнокод, лишь бы позеленело, а внутренние кишки как-нибудь потом порефакторим». Хотя если качественно дробить на мелкие части и писать правильные тесты (что поднимает вопрос, кто будет писать тесты на тесты), то по идее «если оно крякает как утка, то это скорее всего утка».

Разница с листочком только в том, что он вас не проверит. И через полгода не закричит, что вы что-то сломали при рефакторинге/внесении новой функциональности.

А так тоже самое. Хотя я и листочками пользуюсь.

Вы слишком формально подходите, как мне кажется. Если человек хочет писать говнокод - никакая методика не поможет. А нормальному человеку TDD помогает меньше косячить. Конечно, если вы внимательный и сосредоточенный гений и не ошибаетесь, вам оно может и не надо.

Звучит как «пишите любой говнокод, лишь бы позеленело

Угу, а потом встречается

в тестах:
equal(plus(2, 3), 5);
equal(plus(1, 2), 3);
equal(plus(3, 4), 7);
equal(plus(-1, 2), 1);

в коде:
int plus(int a, int b)
{
   if(a == 2 && b == 3) return 5;
   if(a == 1 && b == 1) return 3;
   if(a == 3 && b == 4) return 7;
   if(a == -1 && b == 1) return 1;
   return 0;
}

Вы правда считаете, что в этом виновато TDD?=)

Вы правда считаете, что в этом виновато TDD?=)

Да. Это буквальное решение по принципу «обеспечить прохождение всех тестов» и «код пишется только в том объеме, который достаточен для прохождения теста».

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

Да.

Тогда поясните, что мешает писать такой код без TDD?

Это буквальное решение по принципу «обеспечить прохождение всех тестов» и «код пишется только в том объеме, который достаточен для прохождения теста».

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

И поэтому в нормальных конторах тестировщик и программист — два разных человека.

Естественно. У меня тоже так. Это ортоганально с TDD. Они в основном занимаются приемочными тестами и отслеживанием качества на бою.

Так в чем вы видите проблему при использовании TDD?

Да, в общем, ни в чем. Просто надо понимать границы применимости метода. Да и метод ли это...

Тогда поясните, что мешает писать такой код без TDD?

Факт, что тесты, которые будут прогоняться заранее неизвестны.

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

Тем не менее. Бывают краевые случаи. Причём бывают редкие краевые случаи. Например, simcity.exe от какого-то старого SimCity не запускается в WinXP. Что делают программисты из MS. Пишут «if (cmd == „simcity.exe“) ....» и там описывают режим совместимости. Потому как вероятность того, что завтр появится ещё одна настолько же глючная (и так же глючная) программа невелика. В бизнес-процессах сплошь и рядом вместо заведения новой роли стоит «if (user == „Director“) ... ». А потом через полгода выясняется, что такие же права надо дать заму, пишется полтысячи тестов на зама, но добавить условие в полтысячи мест (тем более что сам только что написал эти тесты, значит места уже нашёл) проще, чем создавать ролевую систему прав.

Поэтому единственный метод с этим бороться: даёшь программисту ТЗ и задачу «сделать так, чтобы ТЗ соответствовало». а потом специально обученный человек будет всеми силами стремиться найти комбинацию факторов, при которых программа работает неверно.

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

Чушь собачья

Угу, а потом встречается

Красный-зелёный-рефакторинг.

В приведённом коде отсутствует напрочь стадия «рефакторинг». В этом примере проблема не в методике разработки, а в ДНК автора кода.

TDD просто позволяет приблизить покрытие тестами к ста процентам, но если начитаются изменения в требованиях к программе (например, после очередной итерации и демки клиент решает «немного» поменять API), то тут начинается ад - юнит-тесты начинают реально мешать переделкам, вне зависимости от методик разработки.

P.S. BDD рулит. Причём как Behavior-Driven Development, так и Beer-Driven Development.

В приведённом коде отсутствует напрочь стадия «рефакторинг»

Так вот я как раз про то, что TDD даёт постановку цели, которая нормальному рефакторингу мешает. Если цель «написать корректную, расширяемую, красивую программу», то стремишься на каждом шаге её улучшать, иногда ради красоты и целостности переделывая всё заново (включая API). А если цель «пройти тесты», то интуитивно будешь писать именно как ответ на непройденный тест, а нормально рефакторить, только окогда на код уже страшно смотреть.

У меня такое «TDD» случается когда сроки ставят нереальные. Тогда делается прототип, прогоняется тестами на основные use-case, где тесты не прошли, ставится минимальная заглушка «чтоб работало и не сильно глючило» и в таком виде сдаётся, а уже потом в более спокойной обстановке приводится к нормальному виду (как правило с почти полным переписыванием).

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

А это вообще от лукавого желание. Тесты - они не мешают, они как раз дают гарантию, что старый API не сломан. А изменения нужно вводить инкрементально, старые методы депрекейтя. А то забив на тесты, ты получается забиваешь на клиентов кода. Рефакторинг без тестов - это отчаянный переколбас, который может запросто что-то сломать.

когда сроки ставят нереальные.

Ну с кривым менеджментом вообще все весело получается. Сколько раз сталкивался, если менеджмент хромает, можешь смело забыть все, что учил долгие годы, и писать как студент третьекурсник. Только вот это с точки зрения менеджмента просто пилить сук, на котором сидишь. Ну да ладно, это уже на их совести.

Тесты - они не мешают, они как раз дают гарантию, что старый API не сломан.

Вот это я и имел в виду. При разработке реализуется функция f(a,b) после написания 60% кода выясняется, что на самом деле должно быть f(a, b, c) (например, добавили контроль доступа). И в этот момент при использовании TDD возникает очень сильное желание прикрутить любой костыль, чтобы не ломать тесты. Например, сделать f2(a, b, c) скопипастив в неё 90% кода из f. Тогда старые тесты не ломаются. Но в коде остаётся неиспользуемая функция

Тесты - они не мешают, они как раз дают гарантию, что старый API не сломан.

Stable API is nonsense. Если на него жёстко завязываться, то невозможно почти никакое развитие.

И зачем иметь гарантию фиксированного API до релиза?

зачем иметь гарантию фиксированного API до релиза?

Представил себе строительство дома: кто-то возводит стены из компонентов фиксированного размера, кто-то производит окна, кто-то двери. Потом эти эти окна и двери будут вставляться в специально оставленные для них проёмы в стенах строящегося здания. И всё бы ничего, но на каждом производстве бегают эффективные менеджеры с лозунгом «Stable API is nonsense» и вносят свои коррективы: давайте выпускать окна длиннее чем у конкурентов, а чтобы не получилось дороже в себестоимости - сделаем их уже, площадь окна останется прежней, зато окна будут длиннее! Производитель дверей не отстаёт: стабильная форма дверей is nonsense! Согласно последним исследованиям учёных, наиболее эффективной формой двери следует считать трапецию - ведь человек сверху уже, поэтому можно сэкономить материалы попутно увеличив энергоэффективность двери за счёт уменьшившейся площади. И т.п.

Потом наступает момент релиза, каждый сдаёт свою работу подрядчику: каменщик возвёл стены, пришли заказанные окна и двери с сответствующих производств. Зовут бригаду интеграторов чтобы вставили окна, двери, проложили проводку, поклеили обои и тп. И оказывается что ничто друг к другу не подходит, хотя каждый потрясает результатами своих тестов: «мы тестировали свои окна на предельные нагрузки, площадь окон до квадратного микрона совпадает с заявленной в проектной документации!», «а наши двери прошли полный цикл заводских испытаний, количество открываний-закрываний на отказ превысило требуемое в два раза, а за счёт новой улучшенной формы двери удалось повысить энергоэффективность на 5%, что так же доказано нашими тестами».

Поэтому переделывать свою работу за свой счёт должен каменщик, ведь он ничего не тестировал, а просто возводил стены согласно чертежу.

О, это мне школьников и ЕГЭ напомнило :)

Есть разница, поменять часть API или поменять вообще все.

Если вы меняете вообще все - либо у вас хромает дизайн, либо специфичная «экстремальная разработка». В первом случае вообще никакие методики не помогут. Во втором - наличие тестов является обязательным условием методики.

Без стабилизиции API вы можете обойтись только если проект небольшой и вы делаете его один.

либо специфичная «экстремальная разработка»

Может быть. Или заказчики специфические, или я с ними общаться не умею.

Зафиксировать требования к проекту, его структуру и граница применения до начала работы получается только если разрабатываю для себя.

При разработке под заказ на начало проекта заказчик очень смутно представляет, чего именно он хочет и ещё более смутно может объяснить. Поэтому проходит несколько итераций пробный результат/корректировка ТЗ заказчиком. Окончательно ТЗ утрясается только когда 90% работы уже фактически сделано (и в этот момент пишутся тесты, остаток работы можно считать, что делается по TDD, но, как было сказано выше, в TDD тесты должны быть до первой строки кода).

А бывает и так: делали систему учёта зарплаты а за два дня до сдачи в эксплуатацию расчётному отделу уточнение «у нас расчётный период с 27 числа по 27-е» и все написанные тесты, где отработан неполный месяц, внезапно становятся неверными, потому как в «феврале» с 27.01 по 27.02 31 день...

Есть разница, поменять часть API или поменять вообще все.

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

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

Но как только один и тот же код станут без тестов править несколько людей, начнётся ад.

С этим полностью согласен. Или должны уже быть тесты, или один модуль — один человек (ну или пара в стиле XP).

как маленький прям, хочется то, не хочется сё. заведи себе специально обученного человека с линейкой, который будет херачить тебе по пальцам когда тебе чего-то там «хочется». ну или огребай потом от другого человека когда ты из-за своих хотелок устроишь бардак в проекте и зафейлишь рефакторинг

устроишь бардак в проекте

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

Бардак в проекте появляется при глобальном использовании TDD.

аналитика уровня «земля налетит на небесную ось»

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

что вообще перпендикулярно отсутствию бардака в коде. если у быдлокодера хотелка чешется - он при любой спецификации херни наворотит

если у быдлокодера хотелка чешется - он при любой спецификации херни наворотит

При TDD его тяжелей заставить нормально писать. Также как натаскивая ученика на ЕГЭ почти невозможно дать нормальную научную картину мира. Цели противоположные.

При TDD его тяжелей заставить нормально писать. Также как натаскивая ученика на ЕГЭ почти невозможно дать нормальную научную картину мира. Цели противоположные.

все аналогии натянуты. и эта тоже. с позиции beer-driven-development имеем следующее.

реквест от Васи Пупкина, что в APi надо поменять MakeAllFine/2 на MakeAllFine/3.

если интерфейсы только в разработке, то имеем 15 тестов которые поломаются. Если Вася в прошлый раз поллитрой проставился - вообще гавно вопрос. Сделал и забыл, что вообще было MakeAllFine/2.

интерфейс прошел тестрование, написали 2,5 новых внешних модуля, на согласование ушло 1050 тестов. Вася _реально_ парень адекватный, в отличии от тех _лохов_, что писали те 2 модуля и всегда проставляется курвуазье? Ок.

интерфейс не менялся 2,5 года, используется в 110 модулях у 20 заказчиков на 4 континентах, написано 100500 тестов. Слышь ВАСЯ, тема конечно интересная, но БЕЗ БУТЫЛКИ ясно, что без нового мажорного релиза это не выйдет.

интерфейс не менялся 2,5 года, используется в 110 модулях у 20 заказчиков на 4 континентах

То есть получаем, что помогающие зафиксировать интерфейс тесты до предрелизной подготовки не очень-то и нужны. Что и требовалось доказать.

А в случае языков со статической типизацией вообще грустно: изменил в графической библиотеке тип координат с целых на вещественные — переписывай почти все тесты.

интерфейс не менялся 2,5 года, используется в 110 модулях у 20 заказчиков

Вот интересно, почему это не мешает фирме 1С раз в 2-3 года перелопачивать весь API (на который как бы завязано не менее нескольких тысяч разных внешних отчётов, обработок, программ импорта/экспорта и т.д.)

изменил в графической библиотеке тип координат с целых на вещественные — переписывай почти все тесты.

Для этого существуют typedef-ы.

Для этого существуют typedef-ы.

Это если изначально сделал typedef int coord; struct point { coord x, y, z; }.

А если у тебя struct point { int x, y, z; }, то не будешь же делать typedef double int;. Или будешь?

Или будешь?

Будешь изначально так делать. А в приложениях, работающих с низким уровнем, такие синонимы вообще обязательны.

Плохой дизайн - не оправдание ненужности тестов.

Быдлокодеров не надо заставлять писать программы. Их надо гнать ссаными тряпками из профессии.

Быдлокодеров не надо заставлять писать программы.

Где ж ты столько не-быдлокодеров найдёшь... или программы должны быть маленькие и прекрасные, а промышленное программирование — от лукавого?

Это проблема должна решаться повышением качества образования, а не подгоном всей отрасли под идиотов.

Это проблема должна решаться повышением качества образования, а не подгоном всей отрасли под идиотов.

Если бы можно было повышать уровень образования без неизбежных социальных потрясений, массовых расстрелов и прочего трэша, то на Марсе давно бы уже яблони цвели. Но в реальности мы имеем то, что имеем - 99.99% населения интеллектом не сильно отличаются от трехлетних шимпанзе. И индустрия должна строиться исключительно с рассчетом на этот уровень человеческих ресурсов.