А это разве разрешено по NDA?

PashaPash, это в NDA, насколько я помню, не оговаривается...хотя, надо перечитать 

Самое прямое. Если за проявленную инициативу в случае ошибки будут по рукам бить, то инициатива уйдет на нет.

Разрешить девелоперу самому решать писать или не писать тест. Чуешь разницу? Об этом я и говорил.

Да, вывод верный. Ну и что?


Это ДАО пришло. Вот только иногда все же нужны именно юнит тесты.

Отличный прием, сэр. Ниже пояса.
Подход такой: есть функциональность, ты в ней не совсем уверен (напиши банальную сортировку); пишешь тесты; стразу появляется уверренность.
Если коротко: не уверенности + тест = есть уверенность.

Остальные 40-30% кода настолько тривиальны (отображение данных) либо настолько легко проверяются (открыл страниуц, а тебе прямо в лицо баг), что тесты им не нужны.


Хмм, настолько жесткой НДА я никогда не видел. Т.е. вообще ничего никому нельзя рассказывать? Такой жести я не встречал.  Звиняй. 
Если можно выложить НДА или в личку, то я бы хотел ее глянуть.

Собственно, пока перечитывал NDA, сделал вывод, что списком инструментов таки поделиться можно 
Только вряд ли в этом списке кто-то что-то новое увидит...Думаю многие тут юзают что-то из Jirа/TargetProcess/CruiseControl/etc..., или всё вместе...

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

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

;)
Для существующего кода сделать "+тест" дороже, чем писать тесты вообще на все с самого начала.
Писать тесты до кода дешевле, чем писать их после.
Вывод - писать тесты сразу и на все подряд.

Ручная прогонка smoke нашего текущего проекта - открыть все страницы, сделать crud операции со всеми сущностями, проверить что хотя бы не упало нигда - 2 часа работы QC. Да, QC - низкооплачиваемые негры, но при 3-4 билдах в неделю набегает довольно ощутимая сумма. Кстати, билд чаще всего заворачивают по проваленному smoke. И манагеру при этом лезут в голову глупые мысли, типа "да что у этих девелоперов с руками". :( Легко проверяется != дешево. Хотя, все зависит от долгосрочности и масштабов проекта. 

А вот это уже действительно иногда, редко и только на сложные куски.

Добавлено @ 20:19
Предлагаю с обсуждением TDD завязать, т.к. чистый тру-TDD тут все ненавидят (я в том числе).

Это сообщение отредактировал(а) PashaPash - 9.11.2009, 20:19

Не все так однозначно (нет чисто черног и чисто белого). Любой тест требует затрат времени и сил на создание и поддержку.

У меня на проекте, есть части системы цена некритической ошибки в которой низка. Это, навскидку, админка сайта. Пользуется ей 3-4 человека. Которые емею прямой контакт с нами. Простой баг фиксится в течении часа. Деплоиться либо сразу же (3-4 минуты недоступности сайта) либо ночью.


Опять переворачиваешь мои слова в нужную тебе сторону. Это НЕ то что мы обсуждаем. Мы обсуждаем то, как я могу быть неуверен в 60% своей функциональности.


Я меняю код конкретной страницы именно ее я и запускаю на smoke. Если меняемый мною код затрагивает множество страниц, то скорее всего на него есть тест. Либо функциональность некритическая.


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


  

Ну, опять же, зависит от проекта. У нас на основном проекте админки нет, а изменение в любой сущности ведет (потенциально) к пересчету кучи данных (предметная область такая :*( ).  Т.е. некритических мест практически нет.


Если точнее - как ты можешь быть уверен в оставшихся 40% 


У нас есть фунциональные тесты, которые все равно это класс покрывают. А если не покрывают - значит класс сам по себе существует, и вообще в приложении не нужен. Т.е. у нас на основе тестов и покрытия делается дизайн всего приложения, или по крайней мере крупных кусков, а не отдельных юнитов.
Пытаться ввести TDD на уровне юнитов - это вообще гибельная затея, т.к. рефакторинг чего-то крупнее класса потребует написания новых тестов и переписывания старых. В TDD тесты не меняются во время рефакторинга, по определению. Есть строгие фазы, red-green-refactor, и сама фишка стадии refactor - получить красивый код того, что наколбашено на стадии green, и при этом не трогать тесты. Т.е. при "TDD" через unit, а не функциональные тесты, всегда есть два плохих выхода
- переписывать тесты на стадии refactor - что нехорошо и очень дорого, и на самом деле не TDD
- отказаться от рефакторинга кусков крупнее класса/метода (юнита) - что тоже неприятно, и не TDD, т.к. тесты не задают дизайн приложения.
Обычно выбирают первое, что ведет к непрятным расходам (манагер слышыт "я рефакторил, пришлось переписать туеву хучу тестов ради нормального кода") и довольно тупой работе. А еще при этом девелопер выбрасывает код, который он писал. Даже хуже, на стадии red он знает что код тестов придется выбросить на стадии refactor. А это снижает мотивацию до нуля. --> вырабатывает строгую ненависть к слову TDD.
Ты скорее всего пол года шел именно этим путем, судя по уровню внутренней ненависти ;)

А я о чем???   


Странно. Я вот специально перечитал ветку. И не нашел этого вопроса. Нашел в точности противоположный, на который отвечал.


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

Однажды на встрече с синоптиками товарищ Сталин спросил: "Какова вероятность того, что прогнозы погоды верны?". "40%" - отвечали ему синоптики. "А вы предсказывайте наоборот" - посоветовал им тов. Сталин.
У меня просто другое понятие "уверенности", которое не совпадает с уверенностью с точки зрения разработчика. Точнее, совпадает, но с понижающим коэффициентом 

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

Гадание на кофейной гуще. С чего ты взял что ЗНАЕШЬ как я мыслю?

Если включить думалку, то из моих ответов будет ясно, что 40% это не код в котором я УВЕРЕН, а код на который нецелесообразно (по мнению программиста) писать тесты. В эти 40% входит некритичная функциональность, функциональность с низкой ценой ошибки и, только сейчас, код в котором я уверен.


У меня НЕТ ненависти к ТДД. Я считаю его ОТЛИЧНЫМ инструментом дизайна публичного интерфейса класса. И считаю, что в других случаях ТДД излишне. Что я и сказал пару страниц назад.


Мы НЕ обсуждаем TDD.


С твоих слов (лень искать цитату): ты запускаешь только те юзкейсы которые (по твоему мнению) затрагивают проводимые изменения. Допустим ты 2 часа кодил. Собрался комитить. Запустил ВСЕ тесты. Десяток повалилось. Какое конкретно изменение сломало систему?


Нивопрос.

А кто говорил про дизайн всего приложения? ТДД дизайнит публичный интерфейс класса (юнита). Больше ничего (ИМО). Для дизайна приложения в целом есть еще целый вагон техник.


Тут какая-то ошибка закралась. 
Рефакторинг -- изменение кода БЕЗ именения функциональности. Тесты -- фиксируют некую функциональность. Изменяешь тесты -- изменяешь функциональность. Т.е. не рефакторишь, а кодишь.

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

СУВ, ivashkanet

Я знаю как мыслят девелоперы, работа у меня такая :(

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

"не по моему мнению" а по мнению студии, что немного более обоснованно. или вообще все тесты. Тесты валяться не просто так, "не работает". Они при этом вполне нормальные следы оставляют, в виде stack trace, или конкретных ошибок, "получили 4 вместо 5". Ну и при 2-х часах кодинга не оценить возможный impact на существующий функционал - это как-то из области фантастики.

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

TDD дизайнит публичный интерфейс чего угодно. Есть понятие Acceptance Test Driven Development, собственно, его мы и используем. Есть Unit Test-Driven Development, тот самый с тру-юнит-тестами, его мы ненавидим всей конторой  Вагон техник - это хорошо, но их можно вполне успешно совмещать.


Может я как-то не так объясняю...
1. Рефакторинг -- изменение кода БЕЗ именения функциональности.
2. Тесты -- фиксируют некую функциональность.
3. Юнит-тесты -- фиксируют некую функциональность одного юнита (класса или его метода)
4. Тесты не изменяются на этапе рефакторинга
5. Функциональность одного юнита (класса или его метода) не изменяется на этапе рефакторинга
6. Функциональность и публичный интерфейс класса не изменяется на этапе рефекторинга

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

Если в цепочке есть ошибка, ткни пальцем, потому что я ее не вижу.

Конкретный пример. 
- Есть класс A, c методом SetLight(bool isOn, double brightness). 
А не виден конечным пользователям приложения (вполне типично для web, там видны только контроллеры и presentation model). Но он тем не менее A.SetLight - вполне так юнит (наименьшая единица, которую можно протестировать).
 - Есть тесты на A.SetLight
 - Есть вызывающие его классы B и C. Возможно, через интерфейс Ia.SetLight(bool).
 - Есть тесты на B и C, мокающие Ia.SetLight(bool) (тру-юнит тесты, тестирующие один юнит)

Как провести рефакторинг, в процессе которого SetLight начент принимать один параметр LightSettings (Introduce Parameter Object), и при этом не переписать тесты для B и С?
Как провести рефакторинг, который выделит из A какой-то кусок в подкласс (Extract Subclass) и при этом не переписать тесты на A.

Вы дизайните так круто, что рефакторинг совсем не нужен? Или принимается волевоевое решение не рефакторить ничего крупнее юнита? Или у вас определение юнита другое?

Ок, идем по другому: C чего ты знаешь как Я мыслю?

У нас разные понятия TDD. C моей точки зрения твой подход -- не ТДД. А несколько постов назад мы договорились не трогать ТДД.


Что-то у меня отпало желание продолжать. Наш камень преткновения -- разные определения ТДД. На этом и закончим.

Ты ведь девелопер, а все девелоперы с точки зрения PM-а мыслят примерно одинаково :(

Кстати, грустный анекдот про Agile. Статья http://en.wikipedia.org/wiki/TargetProcess была убита из википедии за "незначимость, незаметность софта (в качестве значимости приведены только ссылки на выигрыш minor industry award (Jolt)), и употребление жаргонизма 'Agile project management'".
Как-то обидно даже, вроде местный (минский) продукт :(

Это сообщение отредактировал(а) PashaPash - 12.11.2009, 15:26

привет всем.

Согласен с Любителем, почти во всем... Даже не по себе как-то ))

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


Это сообщение отредактировал(а) tol05 - 14.11.2009, 01:09

В чем именно согласен? ;)


В паттерне MVC все, кроме модели, - это UI (Presentation Layer). Контроллеры, и даже часть View (клиентский javascript, например) вполне так подлежат тестированию.