А вы программируете по TDD?

тем не менее, tdd вылезло из смолтока, с его ультрапоздним связыванием, полноценным repl, браузером классов на рефлексии и прочими нынче модными штуками :)

Что тестировать, если программер отправлен в свободное плавание?

что тестировать? купальный костюм

он пишет на языке с полноценным REPL и ультрапоздним связыванием, поэтому не только код рождается на кончиках пальцев, но и вообще сама архитектура

моя бабушка курит трубку (с)

Можешь думать, что хочешь

спасибо что разрешил

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

<sarcasm>в таком разе видеоконференцию проще реализовывать IRL в баре с пигом, а компьютеры - ну их нафиг</sarcasm>

Конца не существует, как и предела совершенству

терпеливые у вас заказчики

Тесты в TDD ничего не тестируют. Они не для выявления багов предназначены. Тесты - это форма документации, в которой документация записана на языке программирования.

Кажись, сам Кент Бек говорил, что самая большая проблема тестов - в их названии. Из слова «тест» кажется, что они должны что-то «тестировать», хотя это не так. Тесты должны документировать поведение.

Тесты в TDD ничего не тестируют. Они не для выявления багов предназначены. Тесты - это форма документации, в которой документация записана на языке программирования.

Ой, йо...

моя бабушка курит трубку (с)

Твоя любовь сосать трубку передалась от бабушки?

кто сказал «сосать»?

Насчет проектирования: истина где-то посредине.

Зато запуск тестов как раз тестирует код на соответствие этой документации. Не формальная верификация по сути.

>Тесты - это форма документации, в которой документация записана на языке программирования.

какой вы страшный человек;-)

А интересно, при сертификации прибора немецкий TÜV или американская FDA согласятся принять документацию к коду в форме ТДД тестов?

>кто сказал «сосать»?

девочки, не ссорьтесь :)

>Тесты - это форма документации, в которой документация записана на языке программирования.

какой вы страшный человек;-)

человек, между прочим, истину глаголет

А интересно, при сертификации прибора немецкий TÜV или американская FDA согласятся принять документацию к коду в форме ТДД тестов?

кто-то путает сертификационные испытания и модульное тестирование?

кто сказал «сосать»?

Трубка -> курение -> сосать.

Трубка -> курение -> сосать.

антитабачные законы штата массачусетс?

антитабачные законы штата массачусетс?

Процесс курения - прямая аспирация посредством рта, т.е. сосание.

Процесс курения - прямая аспирация посредством рта, т.е. сосание.

Вас обманули, можно не сосать :)

Куре́ние — вдыхание дыма препаратов, преимущественно растительного происхождения, тлеющих в потоке вдыхаемого воздуха, с целью насыщения организма содержащимися в них активными веществами путём их возгонки и последующего всасывания в лёгких и дыхательных путях.

Вас обманули, можно не сосать :)

Ok, покажите мне, как можно курить трубку, не сося её.

>кто-то путает сертификационные испытания и модульное тестирование?

Что вы имеете в виду под «сертификационные испытания»? В ТЮФе они до ужаса просты: берется руководство по эксплуатации, читается и соответственно что-то управляется на приборе. Но ТЮФу для сертификации требуется дохрена документов. Могут запросить и описание модулей системы (до сих пор проносило - не спрашивали). И теперь представьте себе их реакцию, когда я им скажу, что документация у нас - ТДД :) Будете посланы дальше, чем видете ;-)

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

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

Так вот периодически перезапускать программу (инкрементальный компилятор, конечно, хорош - но далеко не всё может подхватить), тыкать во все эти кнопки - потеря драгоценного времени. А написав за 14-20 минут окружение для теста, можно за 0,02-0,05 секунд, в зависимости от окружения, прогонять эту логику снова и снова - и быстро и легко её кодировать.

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

мир очень многообразен, возможно, всего не охватить через tdd

Раз уж такая пошла жара, может кто-нибудь поделится опытом тестирования гуя, написанного на qt?

> как можно курить трубку, не сося её.

вставить в нос?

Да. Вечером тесты, утром код.

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

Практика показала, что подходы типа ТDD оправданы в тех случаях, когда:

1) есть высокая вероятность, что код пойдет в продакшен 2) есть четкое представление о том что и зачем ты делаешь 3) и вообще полный ынтерпрайз.

Если речь идет о НИРе и прототипе, то на тесты выгоднее забить. Быстрее получишь результаты. Все равно до продакшена практически весь код придется переписать по нескольку раз.

> Ага. Сидят Вася и Петя, прожат. Вася хочет проверить вконтакте, Петя - посмотреть порнуху. А они оба молчат и прожат, злые как собаки. И КПД падает от злости и кипящих мозгов, и люди друг друга ненавидеть начинают.

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

Только вот это самое покрытие на практике ничегошеньки не дает.
(Хоть я и сторонник/практик tdd)

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

У меня - даёт

>и теперь пытается активно протолкнуть это самое TDD в купе с pair programming
Парное программирование нах. Проще, имхо, да и логичнее, ввести нормальное регулярное code review.
А ваш манагер беков-фаулеров обчитался. Не к добру это :) Пуcть он лушше услышит про agile manifest.

Жопой чувствую, что c TDD получим больше проблем

Не верь жопе!

А вы применяете ТDD? Какой опыт работы с ним?

Таки да. Скорее положительный.

>А как же возможность проверить, не отвалилось ли чего?
Эээ, так ты пишешь тесты, походу, после кодирования. А это не tdd

>Эээ, так ты пишешь тесты, походу, после кодирования

Ну это когда как. Когда тесты уже есть, естественно я пишу новые до непосредственно реализации новых фич.

А это не tdd

В конкретном случае - без разницы, tdd, не tdd, главное, чтобы позеленели все тесты после рефакторинга :)

Так ведь в тестах ты выражаешь взаимодействие, а не архитектуру. Вроде как ортогональные сущности.

>позеленели
Ну это да :)

если у вас логика прибита к гую - QTest, или что-то вроде того
если логика не прибита гвоздями, а что-нить вроде MV[C,P] - то проще написать юнит-тесты, которые будут дёргать апи, которое дёргают кнопки

Угу. Недавно наблюдал, как при отсутствии архитектуры попытки сделать все через TDD накрывались нефритовым сосудом. И так в течение 2 недель :) .

Вроде как ортогональные сущности.

Я тестами проектирую api, когда уже есть что-нибудь на пощупать, повертеть.

Что вы имеете в виду под «сертификационные испытания»? В ТЮФе они до ужаса просты...

просты они или сложны - это не важно, важно - они есть

Но ТЮФу для сертификации требуется дохрена документов. Могут запросить и описание модулей системы (до сих пор проносило - не спрашивали). И теперь представьте себе их реакцию, когда я им скажу, что документация у нас - ТДД

это называется - «пошли дурака богу молиться...» :)

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

Вы похоже адепт TDD. Можно к Вам за советом обратиться при необходимости?

> Вас обманули, можно не сосать :)

Ok, покажите мне, как можно курить трубку, не сося её.

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

может кто-нибудь поделится опытом тестирования гуя, написанного на qt?

ничем не отличается, инструменты QTest и QSignalSpy

Если речь идет о НИРе и прототипе, то на тесты выгоднее забить

конечно, tdd - это не кнопка «сделать хорошо», это инструмент, и надо его использовать там где надо и когда надо, а не пихать во все дырки

Только вот это самое покрытие на практике ничегошеньки не дает. (Хоть я и сторонник/практик tdd)

Вы бы как-нибудь выражались поточнее, а то непохожи Ваши слова на слова практика

Недавно наблюдал, как при отсутствии архитектуры попытки сделать все через TDD накрывались нефритовым сосудом. И так в течение 2 недель :) .

и правильно, tdd позволяет, среди прочего, детектировать будущие факапы, отсутствие архитектуры - мощная заявка на факап

Вы похоже адепт TDD.

адепт - это как-то оккультненько, скорее пользуюсь и чувствую пользу, ну и сертифицирован слегка

Можно к Вам за советом обратиться при необходимости?

велкам

а вообще просто заводите в /development ветку, там Вам и покритикуют и совет дадут

s/чувствую/ощущаю

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

Отсутствие архитектуры - нормальное явление, когда нельзя передрать готовые решения.

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

если нужно понять какую архитектуру использовать - пишется прототип, тесты для которого писать - ересь

На проектировании, если с тестов начинать

давайте не будем отменять проектирование как процесс, ок?

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

Это примерно аналогично бездумному применению TDD.

Хы, ну тогда сформулируйте пожалуйста четкую границу, где закончилось проектирование и началось программирование. Особенно для extreme development.

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

Это примерно аналогично бездумному применению TDD.

нравится сосать - сосите, кто я такой чтобы Вам запрещать

однако, повторно обращаю Ваше внимание на тот факт, что это для процесса курения совсем необязательно

Отсутствие архитектуры - нормальное явление, когда нельзя передрать готовые решения

Только на начальном этапе. В конце концов архитектура все равно должна сформироваться. А написанный ранее код нужным образом переписаться под архитектуру. Иначе будет экспоненциальный рост сложности разработки и ваЩЩе полная жопа.

ИМХО как созреет проект до тестов, тогда и стоит за них браться.