Уже 7 месяцев применяю принципы TDD. Здоровая для качества кода штука. Вот каk я делаю:
1) сначала осмысливаю задачу
2) делаю поверхностный дизайн
3) пишу тесты
...

TDD (Test Driven Development) или  XP не запрещают делать первичный дизайн. Просто не надo егo изначально продумывать дo костей. V этоm нет смысла, т.к. зачастую оn меняется в процессе разработки.

Написав сначала тесты мы получаем:
1) лучшее понимание того, чтo мы должны сделать
2) уже готовый интерфейс того, чегo мы пишем
3) достаточную базу для проверки нашегo кода.

neutrino, сколько человек в команде, как внедряли, как контролируете, чем из фреймворков пользуетесь? win/web проекты? как организуете тесты? на базе/без? 

PashaPash, Я выбрался козлом отпущения. Всего из 30 программеров пользуются ТДД - 5. Я первый в нашей комманде (12 человек). Я буду как раз контролировать процесс перехода с нативного программинга на ТДД для нашей комманды.
Тогда расскажу как дела обстоят в другой комманде.

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

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

NUnit + ReSHarper, PostSharp (в основном, конечно Laos). Для логгинга юзаем Log4NET.

Проэкты только Win

Как организуем тесты? Немного не понял вопрос. Каждый пишет тесты для своего кода. Есть отдел, который занимается интегрированными тестами - QA. Понятия не имею как он работает. Тесты пишутся в отдельном проекте. Группы тестов складываются по темам в TestFixture-ы ... Например у меня есть AcceptanceTests, PerformanceTests ...

На базе чего?

тесты прогоняете на базе данных или без нее?  Хотя, для win не так актуально.

У нас web, с ним чуть попроще.

У нас примерно так:
1. asp.net mvc, обязательные тесты на уровне контроллеров. Именно TDD-тесты, а не Acceptance/Performance. Т.е. скорее автоматические Regression тесты.
2. CruiseControl.net
 - билд при коммите, с прогонкой тестов не на базе данных, на стабе.
 - ночной билд, с прогонкой тех же тестов на базе данных + деплоймент
3. MSTest + родной MSTest-овый контроль покрытия. Фейл билда при уменшении покрытия на 0.1% от прошлого билда. сурово, но более-менее работает 
4. Студийные FxCop, StyleCop и фейл билда при предупреждениях
5. Обязательный ревью вообще всех изменений, в Crucible.

Первые пару коммитов девелоперы ругались, потом привыкли. 

Насчет парного программирования - я после 4 часов парного программинга обычно выжат полностью, могу только тупить в монитор. Хотя, тут наверное зависит от напарника. 

Это сообщение отредактировал(а) PashaPash - 27.10.2009, 21:29

Решил подключиться к теме обсуждения.
Знать и уметь применять шаблоны проектирования сейчас уже совершенно необходимо иначе топорную систему ничто не спасет от мусорной корзины. Но часто не имея достаточной информации, сложно грамотно спроектировать точки эволюции системы. Сейчас дочитываю уже третий толмуд по теме проектирования ОО-систем (Крег Ларман "UML и шаблоны проектирования"). Он несколько раз указывает на то, что не стоит применять паттерны только ради их применения. Надо трезво оценивать пользу и вред их применения. 
Сам стараюсь их применять по мере необходимости в своих мини-проектах для пробы пера. На работе, как я уже упоминал, мне очень сложно заниматься проектированием и рефакторингом, т.к. собранной конкретной информации по целям и задачам мало; а мышление некоторых для сложной системы на уровне "нажми кнопку -  получишь сообщение Привет" иногда начисто убивает желание что-то совершенствовать.   
Хочу попутно выяснить у социума: есть ли члены команд с внедренным процессом разработки типа RUP (Rational Unified Process)? Если есть, то какая численность и уровень команды? Кто отвечает за претворение в жизнь тех или иных этапов внедрения?

PashaPash, эффективное время работы программиста в день 2-3 часа в обычном проекте и 3-4 (возможно больше, но не думаю) при..., скажем так, более организованном и командном подходе (не хочу говорить agile). 

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

Предлагаю попробовать снизить время работы в паре до 1,5 часа (чисто условно, но 2, ИМО, тоже много) с небольшим перерывом (сделайте себе кофе, переговорите о том что сделали, сделаете, на те же фишки зайдите...).

Кроме того, советую сделайть план того, что бы собираетесь делать. С ним намного проще не отвлекаться на посторонние вещи. С помощью него ваше эффективное время станет еще эффективнее. И обязательно ему следуйте. Успели выполнить раньше? Остановитесь. Не успеваете (это видно задолго до конца 1,5 часов)? Урежте план. Со временем вы будете составлять планы ровно на эти 1,5 часа с легкостью.



Это сообщение отредактировал(а) ivashkanet - 28.10.2009, 10:01

ivashkanet, отличные советы, но лично у меня PP приносит пользу только при 
- фиксе или дизайне чего-то сложного
- обучении нового человека каким-то внутренним фишкам проекта

Т.е. PP - это скорее исключение из общего процесса, чем регулярная практика. К тому же частичные альтернативы, тот же peer code review, имеют (опять же, лично для меня) несколько преимуществ
- оставляют артефакты, хотя бы в виде комментов
- не требуют одновременного участия 
- позволяют разделить знания между n>2 людьми
- не так сильно выедают моск 
- проще воспринимаются PM-ами (те не забывают делить результат на 2)

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

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

PS что-то всех в оффтоп унесло....

Это сообщение отредактировал(а) PashaPash - 28.10.2009, 16:12

PashaPash, Кстати, спасибо. Теперь думаю и мы внедрим FxCop. А что такое StyleCop? Кстати, у решарпера есть такая тема: CleanUp Code. Очень полезная штука. Иногда решает большинство жалоб FxCop-а.

А это хто? Ну ладно, щац я тебя замучаю. Пойду гуглить  Фенькс за тулзы.

Добавлено через 1 минуту и 50 секунд

Это я как пример fixtures привел. 

neutrino, StyleCop - майкросовтовская проверялка стиля кода - порядка методов, имен параметров, пробелов между скобками. Лучше использовать сразу с StyleCop for ReSharper.

У меня PP используется только при передаче знаний. Да и то за счет моего личного времени. Ибо руководство не понимает пользы (да и не хочет понять). Так же как и код ревью и дизайн ревью. 
Наш тимлидер вообще построил такую систему, что каждый обособленно делает свой таск и совершенно не в курсе что делает сосед. Обсуждать такой подход отказывается. Хотя уже несколько раз проект отгребал по этой причине.


+100 
Только планы у меня сразу на весь кусок работы (1-2 недели расписаны по таскам 1-3-8 часов). 



Надо выделять темы. Ты же у нас модер. Работай  

PashaPash, 

Рульная тулза. А че у тебя за контора? Что-то больно серьезный подход.

Выделять особо некуда, только если в курилку. Организация работы это скорее тема для PM, а не для рядовых программистов.

Logic Software. Подход суровый на основном проекте, потому что на прошлой версии (текущем релизе) мы, как выразился ivashkanet, пару раз сильно отгребли :( На аутсорсе и на мелких проектах все не так строго.

Хорошо когда ПМ-ы это понимают и действительно стараются улучшать работу. Но часто "спасение утопающих становится делом рук самих утопающих".


Эхх мечты, мечты. Я не то что Crucible, я ревью хотя бы важных тасков (до и после/дизайн и код ревью) добиться не могу. Во дают  

Я не согласен  А тему надо выделить куда-нибудь отдельно.. Почитать интересно  

Пока оставил топик в этом разделе, как .net-specific.


Спасение утопающих вообще всегда дело рук самих утопающих :( Оставь в стратегическом месте распечатку по теме - и жди 

По поводу внедрения ccnet/Сrucible/tdd/чего угодно. 
Всегда есть куча способов:
1. Убедить PM-а/Тимлида, показав им статью вроде The Joel Test: 12 Steps to Better Code или Best Practices for Peer Code Review. Во второй есть графики, а графики для PM-ов и выше - серьезный аргумент. no joking.
2. Поставить <что-то> на своей машине и активно использовать. Сделать стандартом de-facto. Очень хорошо срабатывает для ccnet 
3. Самому стать тимлидом и творить что угодно
4. Сменить работу

Мы все хотели установить какой-нить форум внутренний. Но наш АйТи ограничил нас до MS SharePoint. Там есть форум, но посты надо писать в HTML коде.  Просто афигеть. В каком веке живем?

Паша, а есть ли что-нибудь бесплатное похожее на вышеупомянутую тулзу? Очень хочется ...

IMHO, во внутреннем форуме вообще смысла нет. Если очень хочется, то есть вполне легальные обходные пути. Установка любого форума на свою рабочую машину, или использование Groove, например.

http://www.reviewboard.org/

Собственно расскажу о своём (не очень большом) опыте разработки в соответствии с процессами...

1. Одна из контор, в которых я работал использовала CMMI...
Типичная вещь - code review...перед каждым коммитом собираются 3-5 человек, и высказывают тебе все замечания, которые в итоге оформляются как faults...собственно после фикса всех замечаний и делается коммит, который Configuration Manager-ы затем сливают с мэйн-бранчем(хотя это, может быть, ClearCase-specific task). Из плюсов такого подхода могу отметить то, что как правило замечания, действительно, как правило, делаются существенные (при условии, что никто не забил на подготовку к ревью). Из минусов - в крупном проекте (over 900 000 LOC) - зачастую девелоперы забивают на подготовку, и выдумывают фолты прямо по ходу ревью. В результате существенные косяки иногда легко пролетают ревью.

2. Во второй работает Agile...
Как таковая, разработка по TDD не используется, Unit Test-ы пишутся, но уже после реализации функционала. 
Continious integration в виде билда после каждого коммита, а также каждую ночь на билд машине собираются все проекты.
Сам я в Agile-методологии, можно сказать, новичок, так что ничего более путного сказать тут не могу  

Поставил style cop, разве что...наверно скоро руки дойдут до его настройки...

Вот именно. А то ругается на всякую хрень. Я например константы в CamelCase ну никак не приму. ИМХО, константы должны быть в ALLCAPS. Да и потом все эти префиксы приватных полей тоже не люблю. Хотя в нашей конторе стандарты говорят писать myField. Лучше писать простые и небольшие классы, тогда и отпадет нужда в этих различиях. Действительно, если и методы короткие, то ничего не стоит отличить local variable от class field, даже если оба написаны lowerCamelCase, а вот всякие префиксы _field, myField, m_field ... только делают код противным. ИМХО конечно.

Пишите короткие классы с короткими методами, и нужда во всяких walkaround-ах просто отпадет сама собой.

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

Continious integration вполне и без agile работает. А если пишете тесты после кода, то это точно не Agile. Agile это скорее общий подход к процессу, чем набор инструментов. Типа веселые офигенно мотивированные профессионалы очень круто и бодро пишут тру-софтину, без всякой там документации, ведь рабочий продукт круче, и кастомер с ними на той же волне. И, кстати, по Agile - если есть рабочий продукт - то тесты и документация не нужны, ведь все уже работает. Шутка, но в ней доля правды.

У нас peer code review, уже после коммита. Хотя, для >100k LOC строгие ревью вполне оправданы.

neutrino, в StyleCop можно свои правила писать. Кстати, стандартные правила - это просто уточненный Design Guidelines for Class Library Developers

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




В последнее время, я всё чаще слышу от коллег фразы типа "неплохо бы попробовать TDD", но пока это только слова.



Так топик и процессы затрагивает вроде как 

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


Вот начал с ерунды, а потом себя же опроверг.
Agile к тестам никакого отношения не имеет. Вообще-то ведется очень много спрорв что такое Agile и что можно им считать, а что нет. 
ИМО, самые главные принципы Agile прописаны в его манифесте. 

Ни слова о тестах. Так же ни слова об отказе от документации и проч. Здесь просто выставлены приоритеты (просто примеры): 
Зачем нам крутая платформа разработки, модный процесс, CI сервер, ... если каждый из разработчиков что-то там ваяет втихаря?
Зачем нам тесты и документация, если нет работающего ПО? 
Зачем указывать на следование контракту, если заказчик недоволен?
Зачем следовать плану, который уже месяц назад потерял актуальность?



Наоборот, есть ненулевая вероятность того, что разработчики устанут и не будут обращать на них внимание.


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


СУВ, ivashkanet

Это сообщение отредактировал(а) ivashkanet - 6.11.2009, 10:20

Так давай, делись деталями процесса  Или делись полным списком инструментов. Т.к. TDD, CI и прочее - это инструменты, которые почти никакого отношения к процессу не имеют.


Там же была фраза про шутку, нет?
Сам по себе манифест Agile, IMHO, это манифест здравого смысла. А про мотивированных девелоперов и проч - это обычное поверхностное понимание Agile. Опять же IMHO. Потому что когда начинающий мененджер видит "Работающее ПО, чем исчерпывающая документация", он читает его как "все ресурсы на написание кода и новых фич, 0 ресурсов на документацию". И дальше у него в мозгу возникает цепочка:
- ресурсы всегда заранее ограничены
- всегда есть запросы на новые фичи (если проектом кто-то пользуется)
- всегда есть выбор - сделать новую фичу, или задокументировать существующий кусок.
- лучше работающее ПО, чем исчерпывающая документация + реагирование на изменения, чем следование плану
И он решает что надо делать yet another feature, а документация подождет.

Проблема в том, что манифест в чистом виде говорит "лучше", но не говорит насколько. Что бы ты, как мененджер, выбрал
1. Проект с 100 реализованными фичами, без документации
2. Проект с 99 реализованными фичами, с полноценной документацией и ровной архитектурой


Может ты просто не умеешь его готовить?  Например, почти все начинают при TDD писать Unit-тесты, что действительно бесполезная трата времени.
IMHO (надо наверное в подпись вынести), TDD бесполезно применять одному, и не очень приятно применять в чистом виде вообще. 

Тесты окупают себя при:
- Хоть немного нетрививальном функционале
- Команде из более чем 2-х человек, с хоть какой-то текучкой
- Выделении времени на рефакторинг
- Наличии test-friendly фреймворка
- При потециальном росте проекта в будущем.

Писать тесты под мелкое win-приложение для одного юзера - бесполезное дело. Не писать тесты для средних размеров web-приложения - очень серьезная ошибка.

Еще одна неочевидная (IMHO) вещь - тест начинает окупать себя не в момент написания. PROFIT приходит когда он вдруг падает при сборке билда, и кривой билд не попадает к QA.


Разработчик не может охватить стоимость ошибки полностью. Стоимоть функционального бага, попавшего в билд это стоимость
- ручной проверки и обнаружения
- прогонки бага через bugtracker, поиска виновника
- время фикса
- повторной сборки билда

Цена ошибки в функционале высока вообще всегда, и обычно превышает дневную ЗП разработчика. 

Я вообще никогда не уверен полностью в функциональности, потому что видел как тривиальные баги заворачивались по 3-4 раза. Разработчики склонны переоценивать свой скилл по написанию безбажного кода, и вообще склонны переоценивать свою роль в создании софта (IMHO 

Добавлено @ 21:22
PS Спасибо за ExcludeStyleCop 

Это сообщение отредактировал(а) PashaPash - 6.11.2009, 21:23

И то и другое подпадает под условия подписанного NDA 

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


Ну.. вообщем, да, но, если речь не идёт о большом рефакторинге продукта или изменении корневых фич. Аджайл - это принцип облегчённого процесса разработки, но всё-таки не принцип "давай-давай быстрей писать!" 


ИМХО, TDD - это зло. В чистом виде, по крайней мере. Впрочем, как и любая крайность...


  


Ээ.. Что-то я не понял. Во-первых, я не мыслю TDD без юнит-тестов. А, во-вторых, я не считаю, что юнит-тесты - это бесполезная трата времени.


Если речь про юнит-тесты - то:
1. Само собой проект должен быть не маленьким.
2. Само собой должен быть тест-фреймворк (а как вообщше иначе?!).
Но, самое главное, когда ИМХО полезны тесты:
1. На начальном этапе проекта, когда толком нельзя "нормально" отлаживать внутренние вещи. Хотя такой ситуации ИМХО просто не должно быть - надо писать в обратном порядке 
2. Если планируется разработка или (особенно) переработка, затраная в архитектурном плане.

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

+1, потому TDD в чистом виде мы тоже не используем.


Один Unit Test тестирует модуль - наименьшую часть приложения, которую можно отдельно протестировать. Функцию, класс, взаимодействие двух классов, но не больше. Т.е. если ты пытаешься протестировать сайт, то пишутся
- тесты на UI
- тесты на каждый метод BL
- тесты на DataAccess
При этом тесты "плывут" при смене архитектуры, и очень дороги в поддержке. На этом внедрение TDD на Unit-тестах обычно и умирает, оставляя в разработчиках жгучую ненавить к TDD в целом 

В TDD тесты - это автоматические regression-тесты. Один тест покрывает тест-кейс, одно или несколько действий на UI, и заодно задейстованные при этом куски BL/DataAccess. TDD тесты не затрагиваются внутренностями архитектуры, и спокойно переживают рефакторинг, расширение архитектуры и прочие внутренние вещи. Основная цель автоматической регрессии - проверить что не поломался функционал в целом, а не какие-то "модули".


1. А если маленький, но вырастет в будущем? У меня софтина из списка с 3 кнопками вырасла в 4 сервиса + тонкий client + штук 5 сервисов внешних. При этом добавлялись только мелкие фичи 
2. Есть ес-но

насчет когда полезны
1. На протяжении всей жизни проекта, и чем больше раз тест падал, тем полезнее. читай - чем раньше тест написан, тем полезнее.
2. Если планируется рефакторинг - сомневаюсь что тесты "вдруг" появяться в момент, когда решат порефакторить. А писать тесты на старый код - дорого и неприятно. 

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

Я, кстати, поговорил с местными QA сегодня. По статистике они чаще всего заворачивают билды из-за ошибок типа "страница не открывается" и "падает по кнопке Save". Т.е. на абсолютно тривиальном функционале, который написан уже года 2 назад, где и логики как таковой нет. Но который девелоперы все еще умудряются случайно ломать. Девелоперы вменяемые, архитектура ровная. Полный прогон билда, кстати, 6 человеко-дней. Название проекта не скажу, ибо NDA ;) Это к вопросу о стоимости ошибки. Бесполезно мне доказывать что тесты не нужны  Потому что все аргументы выше доказывают что тесты не нужны лично вам, потому что лично вы - тот самый несуществующий девелопер, который НИКОГА не лажал (а на самом деле просто лень и нежелание увидеть полную картину)

Хотя, мелкие проекты (до 200 часов), мы типа под Agile вполне колбасим без тестов 

Ну.. Аджайл проповедует чаще смотреть на реальную ситуацию. Аджайл проповедуте нетяжеловесный менеджмент, лёгкость смены тасков и ориентиров. Моё ИМХО 


Абсолютно верно 


Я не считаю, что это есть TDD. Вообще - регрессион-тестирование не может относится к разработке (именно к разработке в плане девелоперов, а не организации проекта). ИМХО, это задача QA-команды. Я не говорю, что это обязательно мануальное тестирование - но в любом случае это не связано с написанием основного кода (что не скажешь о юнит-тестах). А на начальном этапе ни о каком регрессион - речи по определению нет.


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


Мм.. Я не согласен. Я считаю, что писать тесты на "старый код" - это нормально. Если планируются изменения, затрагивающие этот код. Более того, при наличии времени это даже preferred way.


Да, если бы знал. А если не знал - лучше не напишу, чем напишу..


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


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

ИМХО> Тесты до кода писать просто интереснее, Тесты после кода писать нудно. Если проводится рефакторинг старого кода, то тесты на старый код писать необходимо.

А что такое ТДД в чистом виде?   Когда все и вся пишется через тесты? Если да, то это конечно крайность.

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


Полноценные regression-тесты - ес-но задача для QA. Я просто хотел показать что TDD-тесты по смыслу и по подходу ближе к регрессии, чем к unit-тестам. Автоматическая регрессия вообще применима начиная со второго билда. Если билды при коммите кода - то фактически при втором коммите.

"Тесты до/во время кода" тупо дешевле "тестов после" примерно в N раз, N > 10. Т.е написать код, а потом покрыть 10% существующего кода == написать тот же код, сразу покрытый тестами. Опять же, возвращаясь к agile-подходу - ценится возможность внести незапланированные изменения, а не планировать их заранее. И опять же, ценится рабочий продукт, в полном смысле этого слова, а не когда работает только новый функционал.

Ага, а потом появляется шеф, и говорит: что-то ваш тим, Любитель, валит уже 4 билда подряд на каких-то мелочах? доколе? ... лишить компота...снизить зп...все уволены. Потому что 4 билда - это 3-4k$ (условно), и это уже не первый раз.


У нас пока примерно такой подход:
 - Долго пишется один толстый проект (скажем, 20к часов) , под ним обкатывается архитектура, с тестами, dsl, полноценными доками и проч. Где-то между CMMI и Agile.
 - Параллельно в разработке висят 1-2 проекта на той же архитектуре, без тестов и проч. Сплошной Agile, хоть никто и не догадывается.

Я, кстати, работаю совестью первого проекта и манагером группы вторых 

Немного в сторону от темы, но хорошо пересекается с "когда полезны тесты".Технические долги. Очень трезвый взгляд на тесты, рефакторинг, архитектуру и прочие тудушки.

Добавлено через 4 минуты и 32 секунды

Вот поэтому чистый TDD никто и не любит. Я пробовал, действительно крайность, даже на полноценном тестовом фреймворке с рюшекчами, где можно выжать 99% покрытия бизнес логики обычными тестами перед кодом.

Ну.. по крайней мере, я всегда ТДД именно так понимал  Вроде как, само понятие TDD наталкивает на такое определение.


Обрастать может и будет - но всё-таки в большинстве случаев это именно "обрастание", а не "разрастание". То есть "коренная" архитектура не затрагивается. Хотя, конечно, это исключительно из моего (оч скромного) опыта.


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


Хм.. Всё-таки тогда хотелось услышать твоё понимание ТДД. В первую очередь - какие тесты? И кто их пишет? Как? И насчёт покрытия функционала/кода тестами - тоже интересно (грубо говоря, достаточно доли).


Да, конечно, дешевле. Но, я думаю, явно не настолько. И плюс, самое главное, опять-таки - всё зависит от ситуации..


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


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


Ну.. Если проекты подобны - я бы просто считал бы это ветками того же проекта.

А вообще, что-то мы с тулзов совсем перешли на менеджмент.  

Это довольно подробно в вики расписано, но можно тут продублировать.
0. Появляется новыйз use-case (user story). Пользователь зашел на страницу XXX, нажал YYY, увидел ZZZ, при этом в базе был набор AAA, после стал AAAB.
1. Пишется один (!) тест, который все это проделывает. Ес-но все управление на себя наборами данных и прочим стаффом берет фреймворк. В тесте непосредственно два вызова XXX и YYY и последующие ассерты. Формально - это не unit-тест, т.к. покрывает кучу всего.
2. Девелопер убеждается что тест падает 
3. Пишется минимальный код, позволяющий тесту не упасть.
4. Девелопер проверяет что все тесты заработали
5. Рефакторит то, то написал
6. Повторяет.

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

На выходе получается софт, в котором (теоретически) все существующие юзкейсы покрыты тестами, т.е. после (5) tdd-ный тест нахаляву превращается в регрессионнный.

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



Именно настолько, и разрыв может быть и побольше. Проблема в том, что написанию тестов обычно мешает не архитектура (что там, заюзать IoC/DI), а именно сам код, который захочется протестировать. А говорить девелоперам "пишите весь код так, чтобы его можно было потом протестировать" - это взывать к их способнастям телепатов  И опять же, тест понадобится тогда, когда он в первый раз упадет. Как ты предлагаешь предугадывать этот момент? 
Проблема как раз в том, что девелопер почти всегда уверен, что он пишет код идеально, и что тесты - бесполезны. Тесты лично девелоперу не нужны, и он искренне удивляется каждому багу. А еще он может сделать любую задачу за 3 дня. ;)

У них абсолютно другая предметная область  Просто тест-oriented архитектура оказалась очень удобна для наколбашивания проектов без тестов.

Дык, делись списком тулзов.

Т. е. тест должен покрывать именно юзкейс? Тогда AFAIK это функциональный тест. Но (!) тогда он (вообще говоря) никак не сможет быстро отработать. Я всё время мыслил о ТДД именно в контексте "быстрых" юнит-тестов и, как следствие, часто запускаемых.


Вот имено, что юзкейсы. Т. е. это исключительно high level тесты. Грубо говоря - код ими не покрывается. Т. е., я не могу гарантировать что этот класс работает правильно. Он работает правильно при том, как он сейчас используется. Нет, это не есть плохо - но это никак не юнит-тесты.

ИМХО, конечно, но функциональными тестами тоже должны заниматься QA. Ибо они не привязаны к внутреннему коду. Если они это автоматизируют, интегрируют в билд-систему и т. д. Отлично. Но девелоперы, я думаю, если и должны писать тесты - то только юнит-тесты.


Я не очень понял. Что значит "мешает код, а не архитектура"?


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


Дык я вначале того.. послушать зашёл  Уникальных тулзов у меня нет. И, самое главное, особо полезного реального экспиринса по внедрению и интеграции - тоже  

Что у вас за юзкейсы такие? O_o? У нас пока в среднем 0.1-0.2с на юзкейс. Вся фишка как раз в том, чтобы заполучить фреймворк, который по настоящему test-friendly, а не "позволяет использовать тесты".
Кстати, в 2010-й студии есть test impact view, который позволяет запускать только затронутые изменениями тесты, если уж дествительно по времени прижимает. 

Вот это и фишка TDD - когда функциональные тесты пишут девелоперы. Так же особенность TDD-тестов - они не привязаны к внутреннему коду, они вообще не гарантируют что там этот класс есть. Зато они гарантируют что архитектура отвечает реальным требованиям, а не какому-то абстрактному мега-плану (см Agile ;). А еще TDD тесты отлично переживают вообще любой рефакторинг - потому что они тестируют не юниты, которые при рефакторинге колбасит, а общее поведение, которое при рефакторинге не должно измениться.
А код этими тестами отлично покрывается в том смысле, что они его хотя бы исполняют, и проверяют окончательный результат. А если кусок не покрыт - то он, по определению, не нужен. Кроме очевидных исключений.

А написание именно unit-тестов вообще на все - действительно бессмысленное занятие. Они слишком дороги в поддержке, повышают стоимость рефакторинга, мешают новому функционалу, и вообще ведут себя не по agile-овски 

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

Проблемы у TDD такие же, как и у Agile:
- его неправильно понимают
- выбирают неверные инструменты
- ударяются в крайности


В том смысле что архитектура - это общее описание того, как работает приложение. А код - непосредственная реализация задумок архитектора. Простой пример - вызов HttpContext.Current сделает кусок кода практически нетестируемым, как бы не продумывал testeability архитектор.


Скажем, не вся архитектура, а скорее набор паттернов разного уровня + их стандартная реализация. Шаблон приложения, если так удобнее. Полученный из большого приложения выбрасиванем предметной области.

При достаточно количестве данных - я не представляю, как это может быть 01.-0.2 секунды :(


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

Магия ;) на самом деле не нужно вбивать огромное количество данных, для отработки юзкейса достаточно небольшого набора. Это ж не нагрузочные тесты. Время ответа страницы до секунды - вполне типичное требование к веб-приложению. Неправильно ожидать что тест будет работать медленее живого приложения.

Это сообщение отредактировал(а) PashaPash - 7.11.2009, 16:37

Ну.. не всякой страницы. Есть фичи, которые в любом случае занимают время - и это нормально. Но это один (!) тест. А если тестировать весь проект - это явно приличная задержка.. Что-то я всё-таки не понимаю 

Любитель, это задержка в пару минут при сборке среднего проекта. Код дольше компилируется, чем тестируется  Да и прогонка тестов при CI не требует непосредтсвенного участия разработчика.

Не, с CI всё понятно. Непонятно с TDD. Ибо в моём понимании ТДД предполагает частый запуск тестов девелопером. А тесты после билда - в этом ничего нового нет (всё равно, конечно, далеко не всегда эти тесты автоматизированны, но я не отношу это к ТДД).

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

Можно понаблюдать за собой, как типичный разработчик пишет код в среднем таком проекте
1. рисует зародыш ui
2. пишет логику
3. дергает ее из ui
4. правит баги
5. повторяет раз так N
6. коммитает

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

Хотя, все зависит от того, в какой пропорции уходит время на ручную проверку логики по отношению к кодированию. Я пока не виде людей, которые пишут рабочий код правильно и с первой попытки. И вообще его никак не проверяют при этом ;)

Я понял. Автоматизацию тестирования я поддерживаю в большинстве случаев (за исключением уж очень тривиальных только). Но к ТДД это не отношу. Впрочем, это вопрос терминологии.

Ой нафлудили  На выходных отдызать нужно   


Я отнес ее ко второй части абзаца.  

Это его проблема. А не Agile. 

Врядли, скорее всего умею  И чтобы не было недопониманий: я не против тестов, я против TDD (в чистом виде и на 100%-х функциональности).

Ты про TDD или про тесты вообще?


+1 Кроме того: почти все в нашем мире нужно адаптировать под себя (что хорошо одному -- другому смерть Ж)) )


А зачем полностью? Это не точная наука. "Внтуреннего голоса" вполне достаточно. Ведь любую ошибку можно исправить.


Гнилая отмазка. Уж не обижайся.


Ну ты уже понял, Паша, что я с тобой тут не согласен   

  

Паш, у тебя неправильное ТДД. Причем я даже не знаю как тебя переубедить. У тебя скорее FTDD (Functional TDD). И я совсем не представляю как твое TDD может помочь в дизайне приложения.

СУВ, Aikin

Это сообщение отредактировал(а) ivashkanet - 9.11.2009, 10:30

И про то и про другое. Вообще любое тестирование должно поддерживаться всей командой.

В чем именно не согласен? Ты пробовал именно Unit-тесты, перед разработкой? Как unit-тесты могут помочь в дизайне всего приложения, а не отдельных юнитов? Чтобы написать тест на юнит, нужно сначала принять решение о существовании этого юнита, а это решение - и есть построение дизайна. А когда юнит появился - то никакой тест на него не может дизайн изменить.

А FTDD (скорее уж, tests before development) очень классно помогает. Именно тем, что оно определяет дизайн всего приложения, а не тестирует юниты уже в готовом дизайне.
  
Я вообще-то выше написал что у нас не TDD  в чистом виде. Но зато у нас тесты есть, практически на весь функционал, и вся команда понимает их необходимость. А у вас - нет ;)

Переубеждай ;)

Это с точки зрения разработчика - программирование - это исскуство, с неточными числами и загадками.
Внутренний голос разработчика говорит "да подумаешь, это можно исправить, не проблема, работы то тут на 5 минут".
Внутренний голос QA - "опять исправять что-то внутрях, мне из-за этих 5-ти минут все перетещивать. В прошлый раз поверил что функционал YYY не затронет - а там все поломалось. Когда эти криворукие девелоперы научатся код без багов писать"

А вот у манагера все просто. С его точки зрения стоимость ошибки - вполне точная сумма в $. Можно даже прайс нарисовать.
- баг повалил тесты при билде - 5$
- из-за бага билд у QA не запустился вообще - 50$
- баг нашли QA во время smoke - 500$ за все баги
- баг найденный QA во время регресии - 1000$ за все баги
Прайс нашептан моим внутренним голосом, но легко вычисляется из количества людей, через которых проходит билд, их зп, и среднего времени обнаружения первых багов.

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


Мы уже как-то нафлудили несколько страниц. Неохото повторяться.


А потом, через несколько лет успешных и не очень проектов, манагеру открывается ДАО: для проекта дешевле поощрять инициативу программистов и дать им возможность совершать ошибки. Вот только прайс под это дао уже не подведешь.

Добавлено через 3 минуты и 35 секунд

Ну кто сказал, что у нас нет тестов практически на весь важный функционал (60-70% покрытия)? Я такое не говорил.

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

ivashkanet, ты манагер или девелопер? судя по подходу - девелопер 



Т.е. вы не уверены в 60-70% своего кода? 

В чём проблема?   Не вижу гнили 
Осталось только скан NDA предоставить 

А это разве разрешено по 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