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

зачем иметь гарантию фиксированного 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% населения интеллектом не сильно отличаются от трехлетних шимпанзе. И индустрия должна строиться исключительно с рассчетом на этот уровень человеческих ресурсов.

Откуда этот мейнстрим пошел? Из рубиворлда?

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

Это точно! Еще что меня сильно удивило так это то что на собеседованиях сегодня 50% вопросов касаются TDD и Agile.

А зачем ты ходишь на собеседования в быдлоконторы? В Google, Microsoft или IBM таких дебильных вопросов никто задавать не станет.

В гуглы меня пока не берут.

А после быдлоконтор и не возьмут никогда.

Согласен, возможно. Но какие тогда предложения? Куда идти? Например в Украине.

Тесты не нужны.

Запускается — хорошо. Нагружает чем-то процессор — зашибенно, отправляем в продакшн.