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

White OwlTDD это забавный зверек пригодный для расчетных задач. Но в большинстве случаев мы пишем что-то работающее с пользовательскими интерфейсами, а для этого чрезвычайно сложно создать автоматический тест. Поэтому и TDD распространения не получил.
Создать автоматический тест для интерфейса ничуть не сложнее, чем для расчётного модуля. Несильная распространённость TDD имхо вызвана в основном первой "D" - той, что driven. Дело в том, что категорическое требование создавать тесты перед разработкой годится только для хорошо формализованных областей - действительно, в частности, тех же расчётов и конверторов. Для большинства же применений это либо прямой путь к плохому дизайну - и многочисленным рефакторингам до приемлемого состояния - либо просто неудобно. Например, неудобно писать тест типа "заполни поле А и нажми кнопку Б" в тот момент, когда интерфейс ещё не спроектирован и контролы А и Б неизвестны. Если отойти от этого требования, например, в сторону подхода "прототип - тесты - рабочая версия", получается очень даже неплохо.

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

kmawкак тут это TDD имеет место быть?
Очень даже хорошо. Главное, что нужно понять - что хороший тест есть воплощение какого-либо требования к системе. Да, того требования, которое в теории пишут аналитики, управление требованиями итп. Та "бизнес-логика" по сути состоит из набора требований вида "при таких-то исходных система должна реагировать так-то" - значит, тест вносит эти исходные и проверяет реакцию. Всё просто.

ДохтаРЯ прошу прощения , но последние бестпрактисы гласят что мухи ( гуй ) отдельно , а котлеты ( бизнеслогика ) отдельно.
При таком подходе нет проблем использовать TDD для тестировани бизнеслогики. А Гуй пусть оценивает комиссия по эстетике и морали,
Видите ли, ожидания пользователя от системы формулируются примерно так: "Я ввёл текст, нажал на кнопку - и письмо отправилось". Вы можете великолепно протестировать модуль smtp, но если "текст" оказался read-only, или кнопка не нажимается, или нажимается, но не вызывает нужную smtp-операцию - это провал. Функция не работает, пользователь недоволен, автоматическое тестирование провалилось, программист дурак.

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

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

egorychИ вот что я не понимаю возвращаясь, всё же, к заявленной теме - как тут применить TDD, когда программируешь такие кейсы. А ведь именно здесь они и нужны больше всего.
Так и применить. Ввести даты, нажать кнопку и проверить, что строка стала красного цвета. В чём проблема?

F#Это надо обосновать - почему тестирование только отдельных кусков херит всю идею.
Это обосновали почти пятьдесят лет назад, когда провели исследование и обнаружили, что основная тяжесть ошибок в программах приходится не на "отдельные куски", а на их взаимодействие.

F#Например в электрический чайник я наливаю воду вручную, но дальше он кипятит чай самостоятельно. Если он облегчает мне часть работы почему бы его не использовать?
В самом деле. Пару месяцев назад моя жена купила электрический чайник. У него оказалась клёвая фича - после того, как он вскипятил воду, он не отщёлкивает кнопку, а просто термореле отключает спираль. Минут через пятнадцать он снова включается и снова доводит воду до кипения. И так далее. Вы берёте его, тестируете кусок, вставляете в квартиру - и уезжаете, рассчитывая к возвращению иметь чайник кипячёной воды. А приезжая, обнаруживаете в лучшем случае пустой чайник, а в худшем - пожар. Профит кусочного тестирования!

F#абстрагировать UI - объекту отвечающему за бизнес логику подсовывать симуляцию пользовательского ввода, который в ответ на конкретный вопрос выдает заранее записанный ответ.
Замечательный способ сделать огромную кучу работы, которая так ничего и не гарантирует. Всего лишь вместо вопроса "правильно ли один вывод подсовывается в интерфейс" останется вопрос "правильно ли другой вывод подсовывается в интерфейс".

ViPRosа как проверить - правильно ли мой метод рассчитал расписание работ на 50 станков на месяц на 10000 работ?
По требованиям, которые выдвигались к математике метода. В общем так же, как Вы сейчас проверяете вручную - "на одно время и один станок не назначено две разных работы? время простоя меньше 5%? ... все критерии соблюдены? значит, правильно рассчитал"

ViPRosправильный ли я СКЛ генерирую по модели?
А вот это - яркий и классический пример того, чего вообще не надо проверять. Именно наделав таких тестов, ламеры начинают кричать, что TDD - дерьмо.

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

Посмотрите выше про отправку письма. Пользователя интересует сценарий типа "я вбил получателя "Вася", текст "Ты козёл", нажал кнопку "Отправить" - у Васи всплыло "Ты козёл". Именно этот сценарий и нужно проверять тестом. А реализован ли он через smtp, или через icq, или через sql - пользователю наплевать.

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

ViPRos(а про эффективность воще молчу - расписание можно считать 10 часов и 2 минуты,
Лучше не молчать, а думать. Выкатываете требование считать расписание две минуты - значит, вставьте в тест проверку "время расчёта больше двух минут". Вот не поверю, что это Вам не по силам :)

ViPRosСКЛ может быть компактным или 7этажным)
А вот на это снова наплевать. Если модуль генерирует SQL - тот должен быть правильным (с точки зрения результатов во всяких ситуациях) и эффективным (с точки зрения выполнения в БД). Ставя критерием компактность - Вы в лучшем случае занимаетесь фигнёй, в худшем - портите программу.

ViPRosраньше все проги сдавались на тестовом примере (контрольном), так вот проги кроме этого и не умели ничего так что проехали это лет 40 назад
Да, студенты так делали. А те, кто выросли дальше студентов, знают, что тогда же придумали и простой метод против таких прог: разработчику выкатывали один набор контрольных примеров, а реальную приёмку делали на аналогичном, но другом.

F#Многие считают, что основная ценность тестов не собственно в проверке функциональности, а в проверке дизайна: Если трудно писать модульные тесты, значит модели плохо изолированы друг от друга и надо рефакторить.
Вот как раз модульными тестами не стоит увлекаться. Это отличный способ потратить неограниченное количество ресурсов с минимальной пользой для проекта.

White OwlСамое смешное, что при известно растягивании терминологии, любая разработка это TDD. Мы с самого начала хотим "чего-то" это уже можно рассматривать как "тест".
Именно так. "Хотим" - это requirement. Тест - это запрограммированная проверка requirement-а. Именно поэтому автоматические тесты позволяют нам в любой момент понять, насколько система отвечает ожиданиям заказчиков, то есть по сути насколько она близка к завершению разработки. С позиций экстремала-теоретика можно сказать, что набор формализованных требований надо сразу перевести в набор тестов, а далее в тот момент, когда все тесты покажут зелёную галочку - остановить работу и подписать акт сдачи в эксплуатацию.

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

egorychруками это протестировать - проблем нет, проблема в автоматизации таких тестов.
Скажу так: уже лет двадцать как мне не приходилось работать с инструментами, где автоматизировать подобный тест было бы серьёзной проблемой. Наверное, такие ещё сохранились, но я с ними как-то не сталкивался.

petalvikОдной из культовых книг считается "Рефакторинг" Фаулера. Если её почитать, то он по ходу повествования постоянно переносит код из одного метода в другой, потом в другой класс, выносит параметры в поля, потом обратно, через несколько итераций возвращает метод в первоначальный класс, но уже с другими параметрами... Вот как тут писать тесты? Написал и тут же выкинул.
На самом деле писать их довольно просто :) Ситуация, когда в ходе рефакторингов постоянно ломаются тесты, означает типичную ошибку их написания - тесты, слишком погруженные в реализацию.

Хороший тест работает выше уровнем, он проверяет требование к проекту. Как следствие, он меняется вместе с требованиями и в минимальной степени зависит от реализации. Идея инкапсуляции говорит нам, что у объекта есть интерфейс и реализация - так вот, тест работает на уровне интерфейса, причём как правило у довольно высокоуровневых объектов. И вся эта мышиная возня в реализации его не касается; разработчик может выделять методы, классы, переименовывать, объединять, менять алгоритмы - а тест проверяет, что если подать на вход "2*2", на выходе будет "4".

petalvikИзначально было три класса. Постепенно, в ходе рефакторинга кода для улучшения тестирования
"Рефакторинг для улучшения тестирования" уже означает кривизну тестирования. Можно дальше не смотреть.