Re[56]: Применяете ли вы Unit Testing
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.06.09 03:37
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

G>Ну-ну, и как ты подготовишь к будущим именениям? Я знаю только один способ: делать маленькие слабосвязные компоненты и писать меньше кода. TDD обеспечивает и то и другое.

Вот именно это тоже удаётся не всегда.

G>Специально дизайнить с расчетомо на изменения не стоит ибо получится монстр.


ГВ>>Противоречие не устранимое в принципе, как ты ни "понимай TDD".

G>Это ты сам придумал противоречие.

Не, его ввели авторы TDD.

ГВ>>Ага, только придумали его ещё и предполагая плотное взаимодействие с заказчиком, что вообще невозможно, например, в рамках "коробки".

G>С чего ты взял?

С подсчёта на абаке. Поделил число необходимых посетителей на количество квадратных метров офиса.

ГВ>>Ну не приведёшь же ты к себе тыщу пользователей, правда? А с другой стороны, эти самые пользователи, встретив неудачную реализацию чего-то даже и не скажут об этом.

G>Еще как скажут. Community своего продукта лучше создавать с первых версий.
G>Или ты думаешь что в принципе можно придумать программу, сделать её с первого раза удачную, выкатить на рынок и вообще не париться по поводу того что думают пользователи?

Это всё декларации. Красивые и правильные. Я про то, что есть — пользователи далеко не всегда спешат расколоться на мнение о продукте.

G>>>Из этого только вывод что ты не сумел применить TDD.

ГВ>>Из этого только вывод, что ты безуспешно попытался выступить пропонентом технологии ради технологии.
G>Логика на гране фантастики.

Да я в курсе, что сугубо формальная логика иной раз выглядит на грани фантастики. Думаешь, ты меня удивил?

ГВ>>Ты лучше сам скомпилируй краткое определение для TDD (заодно поймешь, может быть, почему даже сам термин сей содержит глубокое внутреннее противоречие).

G>А зачем оно надо? Чем какое-то определение поможет?

Ещё раз. Не увиливай, а дай определение. Нет определения — нет предмета для обсуждения. Мы на техническом форуме, или в гламурокисятнике?

ГВ>>А то, как показывает суровая практика, чем сильнее пропонент отказывается от выдачи определения, тем больше вероятность, что на самом деле он где-то пытается поставить лошадь позади телеги или поделить на нуль. Потому и отказывается от определения — много противоречий всплывёт. Гораздо проще обвинять окружающих в безмозглости.

G>Еще один умный. Тогда давай напиши определение завязывания шнурков, которое что-либо говорит о самом процессе завязывания.

Ага, доказательство по аналогии — крутое доказательство. Гуру, ни дать ни взять — гуру.

ГВ>>Не описание, а "определение". Слона можно долго описывать, но где гарантия, что ты описал не один только хвост? Так что, давай по-порядку: сначала определение, потом описание. А не то определениями я займусь... Бу-га-га.

G>Ты лучше образованием займись.

Эх-х-х... Был бы я министром образования — занялся бы.

AVK>>>>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?

G>>>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.
ГВ>>Не юли. Ты просто не знаешь толком определения TDD, потому и не можешь сравнить одно с другим.
G>Я тоже самое говорил, я не знаю определение TDD, от которого есть толк.
G>И выдумывать его абсолютно нет желания.

Объясняю: определение это не ситуативное явление, подбираемое по мере необходимости. Оно либо есть, либо нет. Толк с него только тот, что отталкиваясь от определения можно в той или иной степени раскрутить всю цепочку описаний явления. Если тебе это не понятно, то...

ГВ>>Не надо подменять предмет обсуждения.

G>Есть вещи которые проще показать, чем описывать. Когда это поймешь не будешь писать тот бред, который написан выше.

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

G>>>И люди сразу же все понимали и начинали применять?

ГВ>>Это только для икспиистов школы Agile постижение IoC нуждается в глубоком озарении. Я даже знаю почему — из-за того, что он нарушает LSP. Гы-гы.
G>И где он нарушает LSP?

Набор вставленных в IoC типов можно проверить только в рантайме.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[57]: Применяете ли вы Unit Testing
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.06.09 04:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, gandjustas, Вы писали:


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

G>>Ну-ну, и как ты подготовишь к будущим именениям? Я знаю только один способ: делать маленькие слабосвязные компоненты и писать меньше кода. TDD обеспечивает и то и другое.

ГВ>Вот именно это тоже удаётся не всегда.

Ну если грамотно применять TDD, то почти всегда удается.
Для маленького независимого куска код достаточно просто написать тесты, поэтому простые тесты почти всегда означают слабосвязный код. TDD рекомендует именно такие тесты.
А что касется объема, то написав "минимально необходимый для прохождения тестов код" код получается действительно минимальным.
Тут главное не ошибиться с тем, где применять TDD, например не стоит надеятся что с помощью TDD и рефакторинга удастся получить ORM, лучше сразу задуматься обиспользовании таких средств.


ГВ>>>Противоречие не устранимое в принципе, как ты ни "понимай TDD".

G>>Это ты сам придумал противоречие.
ГВ>Не, его ввели авторы TDD.
Ну дай ссылку на автора TTD (Бека) где он говорит о таком противоречии.

ГВ>>>Ага, только придумали его ещё и предполагая плотное взаимодействие с заказчиком, что вообще невозможно, например, в рамках "коробки".

G>>С чего ты взял?
ГВ>С подсчёта на абаке. Поделил число необходимых посетителей на количество квадратных метров офиса.
У меня 0, хотя я применяю TDD.

ГВ>>>Ну не приведёшь же ты к себе тыщу пользователей, правда? А с другой стороны, эти самые пользователи, встретив неудачную реализацию чего-то даже и не скажут об этом.

G>>Еще как скажут. Community своего продукта лучше создавать с первых версий.
G>>Или ты думаешь что в принципе можно придумать программу, сделать её с первого раза удачную, выкатить на рынок и вообще не париться по поводу того что думают пользователи?

ГВ>Это всё декларации. Красивые и правильные. Я про то, что есть — пользователи далеко не всегда спешат расколоться на мнение о продукте.

Ну и пусть такие пользоваттели есть, что с того?
В любом community 90% — тупо потребители, 9% — участники, и лишь 1% дают заметный вклад (делают плагины, моды итп).
Интересуют эти 9%+1%, но без оставшихся 90% у вас и этих не будет.

ГВ>>>Ты лучше сам скомпилируй краткое определение для TDD (заодно поймешь, может быть, почему даже сам термин сей содержит глубокое внутреннее противоречие).

G>>А зачем оно надо? Чем какое-то определение поможет?
ГВ>Ещё раз. Не увиливай, а дай определение. Нет определения — нет предмета для обсуждения. Мы на техническом форуме, или в гламурокисятнике?
Ок. TDD — методика написания\дизайна кода, при которой тесты пишутся перед тем как написать код.
Что из этого определения ты для себя вынесешь? Цикл red-green-refactor? Правильное применение моков? Принципы YAGNI или KISS?
Пойми что определение ничего не скажет о сути TDD.

ГВ>Ага, доказательство по аналогии — крутое доказательство. Гуру, ни дать ни взять — гуру.

Это не аналогия, напиши тогда возвращайся.

AVK>>>>>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?

G>>>>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.
ГВ>>>Не юли. Ты просто не знаешь толком определения TDD, потому и не можешь сравнить одно с другим.
G>>Я тоже самое говорил, я не знаю определение TDD, от которого есть толк.
G>>И выдумывать его абсолютно нет желания.

ГВ>Объясняю: определение это не ситуативное явление, подбираемое по мере необходимости. Оно либо есть, либо нет. Толк с него только тот, что отталкиваясь от определения можно в той или иной степени раскрутить всю цепочку описаний явления. Если тебе это не понятно, то...

Это тебе наверное непонятно что определение какого либо процесса или методики не скажет тебе ничего о самом процессе.
Я тебе показываю самый простой пример: завязывание шнурков или наматывание портянок.

G>>>>И люди сразу же все понимали и начинали применять?

ГВ>>>Это только для икспиистов школы Agile постижение IoC нуждается в глубоком озарении. Я даже знаю почему — из-за того, что он нарушает LSP. Гы-гы.
G>>И где он нарушает LSP?

ГВ>Набор вставленных в IoC типов можно проверить только в рантайме.

Я привел определение LSP, сформулированное самим автором принципа, покажи что IoC контейнер его нарушает.
В определении нету ни слова о проверке времени типа.
Re[58]: Применяете ли вы Unit Testing
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.06.09 04:49
Оценка: -1 :)
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>>Ты лучше сам скомпилируй краткое определение для TDD (заодно поймешь, может быть, почему даже сам термин сей содержит глубокое внутреннее противоречие).

G>>>А зачем оно надо? Чем какое-то определение поможет?
ГВ>>Ещё раз. Не увиливай, а дай определение. Нет определения — нет предмета для обсуждения. Мы на техническом форуме, или в гламурокисятнике?
G>Ок. TDD — методика написания\дизайна кода, при которой тесты пишутся перед тем как написать код.
G>Что из этого определения ты для себя вынесешь? Цикл red-green-refactor? Правильное применение моков? Принципы YAGNI или KISS?

Если определение сформулировано в рамках существующей терминологии, то вынести из него можно очень много. Да, в определённой степени из него логически следует и YAGNI, и KISS, и куча всего остального. И то, что чем больше автогенерилок тестов — тем лучше для такого подхода. По крайней мере, всех удастся загрузить работой.

А ещё определение ставит некоторые интересные вопросы, например, откуда берутся спецификации на тесты?

G>Пойми что определение ничего не скажет о сути TDD.


Наоборот. Как раз оно то и говорит.

ГВ>>Ага, доказательство по аналогии — крутое доказательство. Гуру, ни дать ни взять — гуру.

G>Это не аналогия, напиши тогда возвращайся.

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

ГВ>>Объясняю: определение это не ситуативное явление, подбираемое по мере необходимости. Оно либо есть, либо нет. Толк с него только тот, что отталкиваясь от определения можно в той или иной степени раскрутить всю цепочку описаний явления. Если тебе это не понятно, то...

G>Это тебе наверное непонятно что определение какого либо процесса или методики не скажет тебе ничего о самом процессе.

Именно что оно-то обычно о многом и говорит.

G>Я тебе показываю самый простой пример: завязывание шнурков или наматывание портянок.


ГВ>>Набор вставленных в IoC типов можно проверить только в рантайме.

G>Я привел определение LSP, сформулированное самим автором принципа, покажи что IoC контейнер его нарушает.
G>В определении нету ни слова о проверке времени типа.

Будь применение IoC полностью LSP-compliant, можно было бы именно компилятором проверять наличие тех или иных типов. А так, если на вход поступает IoC-контейнер, то мы имеем право только предположить наличие в нём объекта того или иного типа. А это заставляет вводить в код дополнительные проверки, условия и т.п. То есть в прямом смысле добавлять в клиентский код зависимости от реализации (сиречь — содержимого) IoC-контейнера.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[56]: Применяете ли вы Unit Testing
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.06.09 07:20
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Кстати в таком случае что-то вроде TDD работает: пишется код, в котором отражается какой API хотелось бы видеть


Т.е. API мы проектируем до написания тестов?

AVK>>UI настроек решарпера.

G>Только к коду это не отностится.

Относится. Это, собственно, код и есть.

G>>>Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями.

AVK>>Можно и показать. Как с тестами быть?
G>В прототипе? Они там не нужны.

Т.е. дизайн мы начинаем разрабатывать до написания тестов?

G>feedback кучи юзеров гораздо лучше одного заказчика с непостоянным мнением.


Он конечно лучше, но о каких то формальных требованиях говорить при этом уже не приходится.

AVK>>Ну вот видишь. Только у меня выводы совсем другие.

G>Какие?

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

G> С помощью каких способов ты можешь выполнит поставленные требования, типа "читаемость"?


С помощью применения моска.

AVK>>Я лучше TDD отправлю в мусорку, чем ради него буду городить дизайн, который приводит к уродливому коду.

G>Повторенное дважды становится правдой?

Аргументы кочились?

G>С чего ты взял что TDD дает тебе уродливый дизайн?


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

G>>>Кроме того понятия читаемости и легкости модификации сильно субъективны

AVK>>Они в большой степени объективны.
G>Докажи.

Ты первый утверждение сделал, тебе и доказывать.

AVK>>С того, что выхлопа 0.

G>Ну это твои проблемы.

А у меня проблем нет. Я, собственно, и не претендую на обобщения, в отличие от.

G>>>1)тесты написанные перед кодом фиксируют требования к этому коду

AVK>>Само по себе ценности не имеет.
G>Имеет, также как имеет ценность упомянутый тобой ниже "специализированный софт".

Докажи

G>Догматичное применение TDD и отказ от высокоуровневого проектирования — тот самый булшит, на который не стоит вестись.


Так я именно об этом и писал все время.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[56]: Применяете ли вы Unit Testing
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.06.09 07:20
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Специально дизайнить с расчетомо на изменения не стоит ибо получится монстр.


Интересное заявление. Скажи, ты как считаешь, зачем нужны паттерны?
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[54]: Применяете ли вы Unit Testing
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.06.09 07:20
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ладно, адекватных примеров не будет, это я понял.


Ну да, овраги.

AVK>>А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает.

G>Да, именно поэтому и придумали TDD.

TDD, как оказывается, только в таких условиях качественно и работает.

G>Из этого только вывод что ты не сумел применить TDD.


Докажи, что причина во мне, а не в TDD.

G>Ну да, ентерпрайз + веб по разным подсчетам занимают от 80% до 95% разработки


Ссылки?

G>, а они все не очень далеко ушли от тех же интернет-магазинов.


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

AVK>>Я не буду длинные кина смотреть, время жалко. Все это я уже миллион раз видел.

G>Судя по твоим постам — ни разу.

Зато судя по твоим постам — первое мое сообщение удивительно точно характеризует аргументацию использования TDD.

AVK>>Например типа Visual Studio.

G>Там уже придумали MEF, тебе он не подходит?

Нет.

G> Чем не подходит?


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

G> Опиши сценарии в которых ты хочешь свой контейнер применять.


Их слишком много, чтобы я описывал это в форумном сообщении.

G>А ты перечитай топик сначала, я уже десяток раз описывал TDD.


Ну, ГВ тут тебе уже ответил.

G>>>А я не говорю что неверно

AVK>>То есть там верно? Да или нет?
G>Может быть и верно, я неочень внимательно читал.

Класс. Просто нет слов.

G>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.


А вдруг то, что ты применяешь, это не TDD?

G>>>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)

AVK>>А чего пробовать. В инете такого навалом, можешь погуглить.
G>Ну напиши словами

Очень в тему.

AVK>>Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно.

G>И люди сразу же все понимали и начинали применять?

Представь себе — да.

AVK>>Думаю, это твоя личная особенность.

G>Ну да, а то чт регулярно темы на форуме возникают, так это люди от нечего делать пишут.

На форуме много интересных вещей регулярно всплывает. Например вопросы, как передать данные из одной формы в другую. Видимо, понимание этого требует неимоверного напряжения моска.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[59]: Применяете ли вы Unit Testing
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.06.09 09:13
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>Ок. TDD — методика написания\дизайна кода, при которой тесты пишутся перед тем как написать код.

G>>Что из этого определения ты для себя вынесешь? Цикл red-green-refactor? Правильное применение моков? Принципы YAGNI или KISS?

ГВ>Если определение сформулировано в рамках существующей терминологии, то вынести из него можно очень много. Да, в определённой степени из него логически следует и YAGNI, и KISS, и куча всего остального. И то, что чем больше автогенерилок тестов — тем лучше для такого подхода. По крайней мере, всех удастся загрузить работой.

Ну напиши свой логический вывод, который из данного мной определения получает KISS.

ГВ>А ещё определение ставит некоторые интересные вопросы, например, откуда берутся спецификации на тесты?

Из требований. Это с первой страницы объясняется.

G>>Пойми что определение ничего не скажет о сути TDD.

ГВ>Наоборот. Как раз оно то и говорит.
Где такую траву берешь?

ГВ>>>Ага, доказательство по аналогии — крутое доказательство. Гуру, ни дать ни взять — гуру.

G>>Это не аналогия, напиши тогда возвращайся.
ГВ>Это именно аналогия. К тому же кривая. Техника завязывания шнурков бантиком отлично иллюстрируется несколькими картинками, если некому показать.
Правильная техника TDD иллюстрируется несколькими скринкастами, если некому показать.
А ты все стараешься ориентироваться на какое-то словесное описание, хотя сам даже не можешь придумать словесного описания гораздо более простого процесса.

ГВ>>>Набор вставленных в IoC типов можно проверить только в рантайме.

G>>Я привел определение LSP, сформулированное самим автором принципа, покажи что IoC контейнер его нарушает.
G>>В определении нету ни слова о проверке времени типа.

ГВ>Будь применение IoC полностью LSP-compliant, можно было бы именно компилятором проверять наличие тех или иных типов. А так, если на вход поступает IoC-контейнер, то мы имеем право только предположить наличие в нём объекта того или иного типа.

Еще раз. откуда в LSP укзание о времени проверки типа? Зачем ты его как аргумент приводишь?

ГВ>А это заставляет вводить в код дополнительные проверки, условия и т.п. То есть в прямом смысле добавлять в клиентский код зависимости от реализации (сиречь — содержимого) IoC-контейнера.

Пример покажешь?
Или хотябы скажи где трава такая забористая.
Re[57]: Применяете ли вы Unit Testing
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.06.09 09:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:


G>>Кстати в таком случае что-то вроде TDD работает: пишется код, в котором отражается какой API хотелось бы видеть


AVK>Т.е. API мы проектируем до написания тестов?

То что ты напишешь — и будут тесты. Только вряд ли это получатся unit-тесты.

G>>>>Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями.

AVK>>>Можно и показать. Как с тестами быть?
G>>В прототипе? Они там не нужны.
AVK>Т.е. дизайн мы начинаем разрабатывать до написания тестов?
Дизайн чего? прототипа? там вообще дизайн не нужен

G>>feedback кучи юзеров гораздо лучше одного заказчика с непостоянным мнением.

AVK>Он конечно лучше, но о каких то формальных требованиях говорить при этом уже не приходится.
Почему же? Конкретный функционал, реквестируемый пользователями, вполне формализуется.


G>> С помощью каких способов ты можешь выполнит поставленные требования, типа "читаемость"?

AVK>С помощью применения моска.
Супер ответ

AVK>>>Я лучше TDD отправлю в мусорку, чем ради него буду городить дизайн, который приводит к уродливому коду.

G>>Повторенное дважды становится правдой?
AVK>Аргументы кочились?
Ты не заметил что сам повтори несколько раз одну и туже фразу, даже не пытаясь обосновать?


G>>С чего ты взял что TDD дает тебе уродливый дизайн?

AVK>С того, что он требует начать проработку до получения и наработки экспериментов по дизайну, а потом висит тяжелым камнем на ноге, удорожая глобальные изменения контрактов в разы.
Во-первых ничего не требует. TDD — не догма.
Во-вторых если делать контракты маленькими, то менять их гораздо легче.

G>>>>Кроме того понятия читаемости и легкости модификации сильно субъективны

AVK>>>Они в большой степени объективны.
G>>Докажи.

AVK>Ты первый утверждение сделал, тебе и доказывать.

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


G>>>>1)тесты написанные перед кодом фиксируют требования к этому коду

AVK>>>Само по себе ценности не имеет.
G>>Имеет, также как имеет ценность упомянутый тобой ниже "специализированный софт".
AVK>Докажи
Что доказывать? Что требования лучше фиксировать хоть как-нибудь, чем держать в голове?

G>>Догматичное применение TDD и отказ от высокоуровневого проектирования — тот самый булшит, на который не стоит вестись.

AVK>Так я именно об этом и писал все время.
Что я писал все время?
Разве я хоть раз сказал что нельзя думать о дизайне не написав тестов? Может ссылку дашь?

Я вроде обратное писал — http://www.rsdn.ru/forum/philosophy/3397798.aspx
Автор: gandjustas
Дата: 20.05.09
см в конце.
Re[55]: Применяете ли вы Unit Testing
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.06.09 09:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

G>>Из этого только вывод что ты не сумел применить TDD.

AVK>Докажи, что причина во мне, а не в TDD.
У многих других проблем нету.

G>>Ну да, ентерпрайз + веб по разным подсчетам занимают от 80% до 95% разработки

AVK>Ссылки?
Не коллекционирую.

G>>, а они все не очень далеко ушли от тех же интернет-магазинов.

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

G>>Там уже придумали MEF, тебе он не подходит?

AVK>Нет.

G>> Чем не подходит?

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

G>> Опиши сценарии в которых ты хочешь свой контейнер применять.

AVK>Их слишком много, чтобы я описывал это в форумном сообщении.
Ну тогда ничем помочь не могу.

G>>>>А я не говорю что неверно

AVK>>>То есть там верно? Да или нет?
G>>Может быть и верно, я неочень внимательно читал.
AVK>Класс. Просто нет слов.
И тебе не советую принимать так близко к сердцу все что пишут в википедии.

G>>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.

AVK>А вдруг то, что ты применяешь, это не TDD?
Ах, пойду застрелюсь.
То что применяю — очень похоже на то что видел в скринкастах.
Re[58]: Применяете ли вы Unit Testing
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.06.09 11:39
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

AVK>>Т.е. API мы проектируем до написания тестов?

G>То что ты напишешь — и будут тесты. Только вряд ли это получатся unit-тесты.

Ээ. Если я начинаю что то делать по API, это вступает в прямое противоречие с идеей "тесты вперед".

AVK>>Т.е. дизайн мы начинаем разрабатывать до написания тестов?

G>Дизайн чего? прототипа? там вообще дизайн не нужен

А если в прототипе нет дизайна, то и прототип не нужен. Главная цель разработки на начальных этапах — получить дизайн, а не реализацию. Я тебе еще раз напоминаю о том, что IoC контейнер в качестве примера я привел отнюдь не случайно. Потому что там главное — именно дизайн, а реализация мало интересна.

G>Почему же? Конкретный функционал, реквестируемый пользователями, вполне формализуется.


Давай я тебе поясню одну интересную вещь. Планирование в стиле — мы решили фиче быть и хоть трава не расти — не очень эффективно. Потому что каждая фича имеет, с одной стороны, цену реализации, а с другой некоторую ценность для пользователя. Загвоздка в том, что оценить стоимость реализации не так то просто, особенно когда речь идет не о одной фиче, а о наборе фич. Поэтому предварительно нужен некий ресеч, который на выходе должен предложить хотя бы примерный дизайн реализации некоторого набора фич. Так как, в зависимости от выбранного дизайна, одна и та же фича может потребовать как большого объема работ, так и получиться практически бесплатно.
И вот на этом этапе выработки предварительного дизайна бывает так, что от TDD один только вред.

G>>> С помощью каких способов ты можешь выполнит поставленные требования, типа "читаемость"?

AVK>>С помощью применения моска.
G>Супер ответ

Какой вопрос, такой и ответ.

G>Ты не заметил что сам повтори несколько раз одну и туже фразу, даже не пытаясь обосновать?


Смешно очень. Ты сам не обосновал ни одного своего утверждения, зато с меня требуешь постоянно.

G>Во-вторых если делать контракты маленькими, то менять их гораздо легче.


А в Киеве дядька.

G>Например не зная некоторых паттернов код с применением этих паттернов станет до ужаса непонятным




G>Легкость модификации наполовину зависит от читаемости, то есть от того насколько хорошо читающий поймет код, на другую половину зависит от хреново формализуемого параметра связности.


Это не доказательство субъективности модификации кода. Есть вполне определенный набор правил, справедливый для любого человека, иначе бы о usability говорить не имело бы смысла. И проблемы с читаемостью кода-спагетти объективны.

G>>>Догматичное применение TDD и отказ от высокоуровневого проектирования — тот самый булшит, на который не стоит вестись.

AVK>>Так я именно об этом и писал все время.
G>Что я писал все время?

Что оппонент дурак и TDD не понимает.

G>Разве я хоть раз сказал что нельзя думать о дизайне не написав тестов?


Ты в явном виде нет, википедия и ряд апологетов TDD — да. Обсуждать же твое внутреннее видение того, что такое TDD, я не собираюсь. Причины этого я уже называл.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[56]: Применяете ли вы Unit Testing
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.06.09 11:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Из этого только вывод что ты не сумел применить TDD.

AVK>>Докажи, что причина во мне, а не в TDD.
G>У многих других проблем нету.

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

G>>>Ну да, ентерпрайз + веб по разным подсчетам занимают от 80% до 95% разработки

AVK>>Ссылки?
G>Не коллекционирую.

Так и запишем — высосано из пальца.

AVK>>Ентерпрайз в общем случае — очень далеко. Если ты не видел ничего, кроме одноразовых бухгалтерий и складов, это совсем не означает, что больше там ничего нет.

G>Не переживай, я много чего видел.

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

G>>>Может быть и верно, я неочень внимательно читал.

AVK>>Класс. Просто нет слов.
G>И тебе не советую принимать так близко к сердцу все что пишут в википедии.

Да нет, у меня нет слов не по поводу википедии, а по поводу обоснованости твоих утверждений. С википедией как раз все впорядке, определение TDD там вполне приличное и доходчивое.

AVK>>А вдруг то, что ты применяешь, это не TDD?

G>Ах, пойду застрелюсь.
G>То что применяю — очень похоже на то что видел в скринкастах.

Внешняя похожесть еще не показатель.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[59]: Применяете ли вы Unit Testing
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.06.09 13:03
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ээ. Если я начинаю что то делать по API, это вступает в прямое противоречие с идеей "тесты вперед".

А ты не думал, что чтобы тестировать нужно уже иметь API?
Тесты для пустого места не напишешь.

AVK>А если в прототипе нет дизайна, то и прототип не нужен. Главная цель разработки на начальных этапах — получить дизайн, а не реализацию.

Еще раз — прототип делается для уточнения функциональных требований.

AVK>Я тебе еще раз напоминаю о том, что IoC контейнер в качестве примера я привел отнюдь не случайно. Потому что там главное — именно дизайн, а реализация мало интересна.

Для него прототип не нужнет ибо все функциональные требования уже известы.

G>>Почему же? Конкретный функционал, реквестируемый пользователями, вполне формализуется.


AVK>Давай я тебе поясню одну интересную вещь. Планирование в стиле — мы решили фиче быть и хоть трава не расти — не очень эффективно. Потому что каждая фича имеет, с одной стороны, цену реализации, а с другой некоторую ценность для пользователя. Загвоздка в том, что оценить стоимость реализации не так то просто, особенно когда речь идет не о одной фиче, а о наборе фич.

Ух ты, правда чтоли? Почитай у Gapertonа про risk-value-cost. Приоретизация вполне может выполнения без целенаправленного продумывания дизайна.

AVK>Поэтому предварительно нужен некий ресеч, который на выходе должен предложить хотя бы примерный дизайн реализации некоторого набора фич.

Это может быть если дизайн приложения изначально кривой.

AVK>И вот на этом этапе выработки предварительного дизайна бывает так, что от TDD один только вред.

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

G>>Легкость модификации наполовину зависит от читаемости, то есть от того насколько хорошо читающий поймет код, на другую половину зависит от хреново формализуемого параметра связности.


AVK>Это не доказательство субъективности модификации кода. Есть вполне определенный набор правил, справедливый для любого человека, иначе бы о usability говорить не имело бы смысла. И проблемы с читаемостью кода-спагетти объективны.


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

G>>>>Догматичное применение TDD и отказ от высокоуровневого проектирования — тот самый булшит, на который не стоит вестись.

AVK>>>Так я именно об этом и писал все время.
G>>Что я писал все время?
AVK>Что оппонент дурак и TDD не понимает.
Видимо ты видишь только то что хочешь.

G>>Разве я хоть раз сказал что нельзя думать о дизайне не написав тестов?

AVK>Ты в явном виде нет, википедия и ряд апологетов TDD — да. Обсуждать же твое внутреннее видение того, что такое TDD, я не собираюсь. Причины этого я уже называл.

Все, не могу уже. Ты определись с кем ты споришь — со мной или с википедией.

Больше не буду писать, а то опять скажешь что я тебя дураком обзываю.
Re[60]: Применяете ли вы Unit Testing
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.06.09 16:57
Оценка:
Здравствуйте, gandjustas, Вы писали:

AVK>>Ээ. Если я начинаю что то делать по API, это вступает в прямое противоречие с идеей "тесты вперед".

G>А ты не думал, что чтобы тестировать нужно уже иметь API?

А ты не думал, что это API сперва надо спроектировать?

G>Еще раз — прототип делается для уточнения функциональных требований.


Еще раз — остаются требования нефункциональные, влияющие на дизайн API.

G>Для него прототип не нужнет ибо все функциональные требования уже известы.


Отлично. Как проектировать дизайн? На бумажке? Или писать код, но до тестов?

G>Ух ты, правда чтоли? Почитай у Gapertonа про risk-value-cost. Приоретизация вполне может выполнения без целенаправленного продумывания дизайна.


А сам ты аргументировать это не в состоянии?

AVK>>И вот на этом этапе выработки предварительного дизайна бывает так, что от TDD один только вред.

G>Так не пользуйся TDD на этапе предваритльного дизайна

Т.е. писать код до тестов?

G>, все равно TDD вступает в игру только когда у тебя есть api для нового функционала, а это значит что ты уже знаешь откуда примерно ты его будешь вызывать.


Ну значит TDD для IoC контейнера практически бесполезен, потому что если уж есть у меня уже API, то дальше все тривиально и не надо что то там серьезное допроектировать. Вполне достаточно обычных функциональных тестов, максимум юнит тестов без всякого TDD. ЧТД.

G>Ты можешь назвать довольно четкие критерии плохого кода, но отсутствие таких признаков в коде не делает его сразу хорошим.


И что? Зато наличие этих признаков делает его плохим. Значит критерий уже небесполезен.

G>Все, не могу уже. Ты определись с кем ты споришь — со мной или с википедией.


С тобой. С википедией у меня расхождений нет. Только я не твое внутреннее видение обсуждаю, а твои внешние, публичные заявления. Чем они там у тебя внутре основываются — мне безразлично.

G>Больше не буду писать, а то опять скажешь что я тебя дураком обзываю.


То есть ничего, кроме как обозвать дураком, ты написать не можешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[60]: Применяете ли вы Unit Testing
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.06.09 22:14
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

ГВ>>А ещё определение ставит некоторые интересные вопросы, например, откуда берутся спецификации на тесты?

G>Из требований. Это с первой страницы объясняется.

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

G>>>Пойми что определение ничего не скажет о сути TDD.

ГВ>>Наоборот. Как раз оно то и говорит.
G>Где такую траву берешь?

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

ГВ>>>>Ага, доказательство по аналогии — крутое доказательство. Гуру, ни дать ни взять — гуру.

G>>>Это не аналогия, напиши тогда возвращайся.
ГВ>>Это именно аналогия. К тому же кривая. Техника завязывания шнурков бантиком отлично иллюстрируется несколькими картинками, если некому показать.
G>Правильная техника TDD иллюстрируется несколькими скринкастами, если некому показать.

Дык, я это уже давно понял: присутствие гуру необходимо для быстрого продвижения ученика. Ох..нная у нас тут война. (c)

G>А ты все стараешься ориентироваться на какое-то словесное описание, хотя сам даже не можешь придумать словесного описания гораздо более простого процесса.


И не собираюсь его придумывать. Речь не об описании процесса завязывания шнурков, мы говорим о TDD. Если это передаваемо только личным присутствием гуру, тьфу, посвящённого в TDD — на фиг такую технику. Вот придёт гуру со своим просветляющим дыханием, а я в ответ дыхну ему табачищем с примесью вишни — и привет, TDD. Разве ж это техника? Нет, для техники саморазвития метод присутствия гуру — вполне себе метод, есть и похлеще, но для технологии (по определению — отчуждаемому и, следовательно, описываемому явлению) это уже попахивает... Я могу тут понаделать индукций по поводу того, кто что тут пытается продать, но это будет не смешно и не в кассу.

ГВ>>>>Набор вставленных в IoC типов можно проверить только в рантайме.

G>>>Я привел определение LSP, сформулированное самим автором принципа, покажи что IoC контейнер его нарушает.
G>>>В определении нету ни слова о проверке времени типа.

ГВ>>Будь применение IoC полностью LSP-compliant, можно было бы именно компилятором проверять наличие тех или иных типов. А так, если на вход поступает IoC-контейнер, то мы имеем право только предположить наличие в нём объекта того или иного типа.

G>Еще раз. откуда в LSP укзание о времени проверки типа? Зачем ты его как аргумент приводишь?

Ха-ха. Молодец, поймал! Да, правильно. Сам по себе LSP совсем не определяет момент проверки типа и под него можно подтянуть и runtime-, и compile-time-проверку. Это как раз устоявшаяся интерпретация LSP — типы должны проверяться в compile-time. IoC прёт буьдозером не столько против самого LSP, сколько против устоявшейся его интерпретации (есть ещё одна оговорка, о ней ниже). Как мы это различили? По тексту определения. Кстати, вот тебе одна из причин того, почему я цепляюсь именно к определению. Каюсь, в данный момент мне не удалось сыграть в заведомый мухлёж: подставить тривиальную интерпретацию вместо формального определения. Но и ты в эту игру играть тоже не сможешь, а не то придётся тебе ощутить дух LSP, и если ты будешь считать, что IoC не нарушает LSP, то это значит, что ты просто не умеешь его применять.

ГВ>>А это заставляет вводить в код дополнительные проверки, условия и т.п. То есть в прямом смысле добавлять в клиентский код зависимости от реализации (сиречь — содержимого) IoC-контейнера.

G>Пример покажешь?
G>Или хотябы скажи где трава такая забористая.

Касательно IoC, до определённой степени "моя трава" дала мне всё же правильное просветление — тут можно засвидетельствовать нарушение LSP, если интерпретировать комплекс "IoC+содержимое" как цельный объект. Улавливаешь фокус? Контракт и функционирование этого комплекса контролируется вообще внешним конфигом, вот в этом и прикол. Ну а сам по себе контейнер и отдельные элементы его содержимого вполне могут соответствовать LSP.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Применяете ли вы Unit Testing
От: minorlogic Украина  
Дата: 27.06.09 13:02
Оценка:
Рассмотрим пример:

Пишем класс "Углы Эйлера", функциональность которых хранить поворот в углах эйлера и конвертирование в матрицу 3*3.

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

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

Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Применяете ли вы Unit Testing
От: Константин Б. Россия  
Дата: 27.06.09 13:15
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Рассмотрим пример:


M>Пишем класс "Углы Эйлера", функциональность которых хранить поворот в углах эйлера и конвертирование в матрицу 3*3.


M>Написали код, после этого возникает резонное желание проверить его работоспособность.

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

M>Убедились в работоспособности, и что теперь делать с проверочным кодом ? Выкинуть , а вдруг придется чет менять через год , может оставить?

M>Оставляем, собственно совершенно очевидно получив "юнит тест".

M>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.


А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.
Re[3]: Применяете ли вы Unit Testing
От: Lloyd Россия  
Дата: 27.06.09 13:17
Оценка:
Здравствуйте, Константин Б., Вы писали:

M>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.


КБ>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.


И чем это будет лучше?
Re[3]: Применяете ли вы Unit Testing
От: minorlogic Украина  
Дата: 27.06.09 13:19
Оценка:
Здравствуйте, Константин Б., Вы писали:

M>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.


КБ>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.


А если через год увидишь новый ,более эфективный способ конвертирования? захочется попробовать , а тестов нету ... стремно как то ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Применяете ли вы Unit Testing
От: Константин Б. Россия  
Дата: 27.06.09 13:19
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Константин Б., Вы писали:


M>>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.


КБ>>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.


L>И чем это будет лучше?


Эти тесты проживут дольше. Можно рефакторить углы и код их использующий, а тесты не изменятся.
Re[5]: Применяете ли вы Unit Testing
От: Lloyd Россия  
Дата: 27.06.09 13:22
Оценка:
Здравствуйте, Константин Б., Вы писали:

L>>И чем это будет лучше?


КБ>Эти тесты проживут дольше. Можно рефакторить углы и код их использующий, а тесты не изменятся.


Зато они будут сложнее, на написание уйдет больше времени и будет сложнее локализовать ошибки.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.