Здравствуйте, gandjustas, Вы писали:
G>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
Опять абстрактное бла-бла-бла. Вот тебе совершенно реальная задача — нужно перепроектировать интерфейс настроек стиля кодирования в решарпере. Причем как оно должно выглядеть, пока тоже не очень понятно. Продемонстрируй, как это задачу решать в соответствии с TDD?
G>4)есть инструменты автоматической генерации тестов (pex), которые позволяют автоматизировать whitebox тестирование
О да, PEX в контексте TDD очень в тему . PEX тем и характерен, что тесты формирует по тестируемому коду, т.е., очевидно, после написания функционального кода.
G>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.
Что то практика демонстрирует кое что другое. А именно классическую картину, навроде ситуации с теми же паттернами — большинство адептов возвели техники TDD в ранг заповедей, и применяют их механически, не очень задумываясь о целесообразности и уместности. А когда просишь обосновать — и вылазят все эти "ты не понимаешь TDD", "иди почитай книжки" и т.п. Вот характерный пример — То ли лыжи не едут ...
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
AVK>Опять абстрактное бла-бла-бла. Вот тебе совершенно реальная задача — нужно перепроектировать интерфейс настроек стиля кодирования в решарпере. Причем как оно должно выглядеть, пока тоже не очень понятно. Продемонстрируй, как это задачу решать в соответствии с TDD?
Так сначала надо определиться как выглядит, а потом применять TDD.
G>>4)есть инструменты автоматической генерации тестов (pex), которые позволяют автоматизировать whitebox тестирование AVK>О да, PEX в контексте TDD очень в тему . PEX тем и характерен, что тесты формирует по тестируемому коду, т.е., очевидно, после написания функционального кода.
А ты думаешь что надо все тесты написать перед тем, как писать код? Это почти нереальная задача.
TDD предполагает итеративную разработку. pex помогает составить fail тесты, sucess тесты пишутся ручками.
G>>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.
AVK>Что то практика демонстрирует кое что другое. А именно классическую картину, навроде ситуации с теми же паттернами — большинство адептов возвели техники TDD в ранг заповедей, и применяют их механически, не очень задумываясь о целесообразности и уместности.
Если любые техники применять не задумываясь, то можно получить негативный эффект. Думать головой надо всегда.
AVK>А когда просишь обосновать — и вылазят все эти "ты не понимаешь TDD", "иди почитай книжки" и т.п.
Они вылазят только когда человек пытается доказать недостатки TDD, или тестирования, или того и другого, нифига не понимая в этом.
AVK>Вот характерный пример — То ли лыжи не едут ...
Здравствуйте, gandjustas, Вы писали:
G>Так сначала надо определиться как выглядит, а потом применять TDD.
Намек ты не понял. Видишь ли какая проблема тут есть — тесты заранее можно написать, только если ты знаешь точно, как будет выглядеть результат, и надо уже налопатить конечный код. Но нередко бывает, что это то и неизвестно. Известны лишь критерии, по которым надо сделать максимально возможный в условиях фиксированных ресурсов результат. И как этот результат будет выглядеть — это как раз и есть основная задача.
G>А ты думаешь что надо все тесты написать перед тем, как писать код?
Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing.
Ну то есть явно TDD тесты после написания кода не запрещает, но эти тесты никакого отношения к TDD не имеют.
G>Если любые техники применять не задумываясь, то можно получить негативный эффект. Думать головой надо всегда.
Ну вот а думанье головой приводит к тому, что, в ряде случаев, применение TDD весьма и весьма ограничено.
AVK>>А когда просишь обосновать — и вылазят все эти "ты не понимаешь TDD", "иди почитай книжки" и т.п. G>Они вылазят только когда человек пытается доказать недостатки TDD, или тестирования, или того и другого, нифига не понимая в этом.
Здравствуйте, thesz, Вы писали:
T>Я на Software People специально ходил на доклады товарищей из Agile, в частности и про TDD. T>Уровень образования чудовищно низок. T>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
Знаешь, я тоже, как журденовский герой, не знал этого сокращения, пока не заглянул после твоего постинга в словарь (хотя использую ежедневно). Потому что у нас это называется "language interpreter shell" :) В то же время _расшифрованная_ аббревиатура была понятна с первой же секунды.
Если ты хотел этим REPL показать уровень, то пример выбран явно неудачно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Так сначала надо определиться как выглядит, а потом применять TDD.
AVK>Намек ты не понял. Видишь ли какая проблема тут есть — тесты заранее можно написать, только если ты знаешь точно, как будет выглядеть результат, и надо уже налопатить конечный код. Но нередко бывает, что это то и неизвестно. Известны лишь критерии, по которым надо сделать максимально возможный в условиях фиксированных ресурсов результат. И как этот результат будет выглядеть — это как раз и есть основная задача.
Если критерии выражаются в коде, то почему бы это не сделать (написать тесты)?
А если нет — значит надо думать как выразить эти критерии в коде, это так или иначе понадобится.
AVK>Ну то есть явно TDD тесты после написания кода не запрещает, но эти тесты никакого отношения к TDD не имеют.
Еще раз: написать все тесты перед кодом — нереальная задача. Это также сложно, как написать с первого раза код, который потом не будет меняться.
TDD предполагает итерационную разработку, сначала пишем несколько sucess тестов, которые показывают что код должен делать в первую очередь, пишем код для них, потом например можно обобщить такие тесты до параметризованных, которые будут "пищей" для pex, чтобы он нашел все сценарии работы.
Потом пишутся fail тесты, pex в этом случае помогает онаружить все fail сценарии.
G>>Если любые техники применять не задумываясь, то можно получить негативный эффект. Думать головой надо всегда. AVK>Ну вот а думанье головой приводит к тому, что, в ряде случаев, применение TDD весьма и весьма ограничено.
Практика показывает обратное, как раз недумание головой приводит к сложности тестирования вообще и TDD в частности.
AVK>>>Вот характерный пример — То ли лыжи не едут ...
G>>А ему всего лишь нужен Func<DateTime>. AVK>Да пофик что там ему нужно. Главное — прекрасная демонстрация того, что применение unit тестирования доходит до полного маразма.
Это демонстрация того что применение ООП доходит до маразма. Вместо создания класса-обертки для Now следовало бы ограничиться передачей Func<DateTime> или вообще инжектить значени Now. Делая это через IoC ему не пришлось бы писать не единой лишней строчки.
Здравствуйте, gandjustas, Вы писали:
AVK>>Намек ты не понял. Видишь ли какая проблема тут есть — тесты заранее можно написать, только если ты знаешь точно, как будет выглядеть результат, и надо уже налопатить конечный код. Но нередко бывает, что это то и неизвестно. Известны лишь критерии, по которым надо сделать максимально возможный в условиях фиксированных ресурсов результат. И как этот результат будет выглядеть — это как раз и есть основная задача. G>Если критерии выражаются в коде, то почему бы это не сделать (написать тесты)?
Затем, что это удорожает. А на этапе, когда ТЗ нестабильно, код нестабилен, тратиться на написание тестов к тому, что через пару дней будет кардинально переделано — значит тратить на ветер.
G>А если нет — значит надо думать как выразить эти критерии в коде, это так или иначе понадобится.
Вот когда устаканится — можно и тесты рисовать.
AVK>>Ну то есть явно TDD тесты после написания кода не запрещает, но эти тесты никакого отношения к TDD не имеют. G>Еще раз: написать все тесты перед кодом — нереальная задача. Это также сложно, как написать с первого раза код, который потом не будет меняться. G>TDD предполагает итерационную разработку, сначала пишем несколько sucess тестов,
Я вот что-то тоже не могу найти подтверждения твоим словам. Впрочем, это даже в названии подхода видно: test-__driven__ development, а не test-covered development, test-supported development или как-то похоже. Слово "driven" сложно интерпретировать иначе, нежели то, что тесты главнее и управляют тем, что и как будет в коде.
G>Это демонстрация того что применение ООП доходит до маразма. Вместо создания класса-обертки для Now следовало бы ограничиться передачей Func<DateTime> или вообще инжектить значени Now. Делая это через IoC ему не пришлось бы писать не единой лишней строчки.
гм... и как ты предлагаешь его "инжектить" в реальный код?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
AVK>>>Намек ты не понял. Видишь ли какая проблема тут есть — тесты заранее можно написать, только если ты знаешь точно, как будет выглядеть результат, и надо уже налопатить конечный код. Но нередко бывает, что это то и неизвестно. Известны лишь критерии, по которым надо сделать максимально возможный в условиях фиксированных ресурсов результат. И как этот результат будет выглядеть — это как раз и есть основная задача. G>>Если критерии выражаются в коде, то почему бы это не сделать (написать тесты)? N>Затем, что это удорожает. А на этапе, когда ТЗ нестабильно, код нестабилен, тратиться на написание тестов к тому, что через пару дней будет кардинально переделано — значит тратить на ветер.
тратится на написание кода, который будет переделан — еще более затратно. ведь с тестами пишется меньше кода, а сами тесты достаточно простые для небольших модификаций.
Если вопрос касается разработки прототипа, то тесты там не нужны, и качество тоже.
G>>А если нет — значит надо думать как выразить эти критерии в коде, это так или иначе понадобится. N>Вот когда устаканится — можно и тесты рисовать.
И как узнать когда устаканились?
AVK>>>Ну то есть явно TDD тесты после написания кода не запрещает, но эти тесты никакого отношения к TDD не имеют. G>>Еще раз: написать все тесты перед кодом — нереальная задача. Это также сложно, как написать с первого раза код, который потом не будет меняться. G>>TDD предполагает итерационную разработку, сначала пишем несколько sucess тестов,
N>Я вот что-то тоже не могу найти подтверждения твоим словам. Впрочем, это даже в названии подхода видно: test-__driven__ development, а не test-covered development, test-supported development или как-то похоже. Слово "driven" сложно интерпретировать иначе, нежели то, что тесты главнее и управляют тем, что и как будет в коде.
Вот от этого и проблемы: люди читают булшит маректологов, википедию, плач тех, кто пытался прмиенить TDD прочитав тоже самое, вместо того чтобы разобраться что такое TDD. Для этого стоит почитать того же Бека (узнать про red-green-refactor), посмотреть исходники с тестами, посмотреть скринкасты про TDD, где пишут код.
G>>Это демонстрация того что применение ООП доходит до маразма. Вместо создания класса-обертки для Now следовало бы ограничиться передачей Func<DateTime> или вообще инжектить значени Now. Делая это через IoC ему не пришлось бы писать не единой лишней строчки.
N>гм... и как ты предлагаешь его "инжектить" в реальный код?
Например так:
public class SomeClass
{
public SomeClass([Dependency("now")]Func<DateTime> now)
{
...
}
}
var container = new UnityContainer();
container.RegisterInstance<Func<DateTime>>("now",()=>DateTime.Now);
var a = container.Resolve<SomeClass>();
Здравствуйте, gandjustas, Вы писали:
G>Если критерии выражаются в коде, то почему бы это не сделать (написать тесты)? G>А если нет — значит надо думать как выразить эти критерии в коде, это так или иначе понадобится.
Ты не понимаешь что такое критерии? Хинт: критерий это не некое решение, которое можно выразить тестом, а параметр оптимизации. К примеру — такими критериями могут быть максимальная читаемость кода, максимальное быстродействие, максимальная масштабируемость, максимально простая реализация, минимальная потребляемая память, максимальная гибкость и т.п.
G>Еще раз: написать все тесты перед кодом — нереальная задача.
Речь идет о TDD и о тестах TDD. При чем тут все тесты?
G>Потом пишутся fail тесты
Этого в TDD нет. Совсем. Ссылочку на определение я привел.
G>Практика показывает обратное
Вот вот, хорошая иллюстрация. На конкретные вопросы расплывчатые абстрактные ответы. Практика показывает ... С чего ты вообще взял, что твоя практика что то такое более менее универсальное показывает? Моя вот — не показывает. Только я почему то из этого не делаю вывод, что TDD это бесполезная фигня.
G>, как раз недумание головой приводит к сложности тестирования вообще и TDD в частности.
Опять та же песня. Голова, значит, не той системы...
G>Это демонстрация того что применение ООП доходит до маразма.
ООП там не в тему, человек явно описал мотивы своего редизайна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Если критерии выражаются в коде, то почему бы это не сделать (написать тесты)? G>>А если нет — значит надо думать как выразить эти критерии в коде, это так или иначе понадобится.
AVK>Ты не понимаешь что такое критерии? Хинт: критерий это не некое решение, которое можно выразить тестом, а параметр оптимизации. К примеру — такими критериями могут быть максимальная читаемость кода, максимальное быстродействие, максимальная масштабируемость, максимально простая реализация, минимальная потребляемая память, максимальная гибкость и т.п.
Во-первых более половины критерием неформализуемы, для них не то что тестов написать, даже адекватную метрику придумать сложно.
Во-вторых при правльном применении TDD будет и хорошая читаемость, и простая реализация, и гибкость.
А что касается быстродействия, потребялемой памяти и масштабируемости, то это уже вопрос оптимизации, а не дизайна.
G>>Еще раз: написать все тесты перед кодом — нереальная задача. AVK>Речь идет о TDD и о тестах TDD. При чем тут все тесты?
Я говорю о всех тестах для конкретного unit. Их может быть очень много чтобы за раз все написать.
G>>Потом пишутся fail тесты AVK>Этого в TDD нет. Совсем. Ссылочку на определение я привел. Википедия теперь сичтается истиной?
G>>Практика показывает обратное AVK>Вот вот, хорошая иллюстрация. На конкретные вопросы расплывчатые абстрактные ответы. Практика показывает ... С чего ты вообще взял, что твоя практика что то такое более менее универсальное показывает? Моя вот — не показывает. Только я почему то из этого не делаю вывод, что TDD это бесполезная фигня.
Ну если считать истинным определение в википедии, то кроме "практика показывает" ничего ответить не могу.
Это примерно как о вкусе устриц рассуждать. Лучше всего это делать с тем кто их ест.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Если вопрос касается разработки прототипа, то тесты там не нужны, и качество тоже.
AVK>Тогда это уже не TDD нифига. В TDD весь дизайн, на 100%, определяется тестами, а не заранее вчерне формируется в прототипе.
Прототип нужен не для дизайна, а для провеки требований и идей.
Я в прототипах не парюсь и пишу логику в button_click, никаким дизайном там и не пахнет.
AVK>>>>Намек ты не понял. Видишь ли какая проблема тут есть — тесты заранее можно написать, только если ты знаешь точно, как будет выглядеть результат, и надо уже налопатить конечный код. Но нередко бывает, что это то и неизвестно. Известны лишь критерии, по которым надо сделать максимально возможный в условиях фиксированных ресурсов результат. И как этот результат будет выглядеть — это как раз и есть основная задача. G>>>Если критерии выражаются в коде, то почему бы это не сделать (написать тесты)? N>>Затем, что это удорожает. А на этапе, когда ТЗ нестабильно, код нестабилен, тратиться на написание тестов к тому, что через пару дней будет кардинально переделано — значит тратить на ветер. G>тратится на написание кода, который будет переделан — еще более затратно. ведь с тестами пишется меньше кода, а сами тесты достаточно простые для небольших модификаций. G>Если вопрос касается разработки прототипа, то тесты там не нужны, и качество тоже.
G>>>А если нет — значит надо думать как выразить эти критерии в коде, это так или иначе понадобится. N>>Вот когда устаканится — можно и тесты рисовать. G>И как узнать когда устаканились?
+1
"устаканились" == нет пожеланий пользователей => утилизация проекта. ( полностью по Паркинсону насчет достижения совершенства в момент краха ).
Здравствуйте, gandjustas, Вы писали:
G>Во-первых более половины критерием неформализуемы
Разумеется.
G>, для них не то что тестов написать, даже адекватную метрику придумать сложно.
Именно.
G>Во-вторых при правльном применении
Опять бла-бла-бла. Ты не мудри, ты пальцем покажи.
G>А что касается быстродействия, потребялемой памяти и масштабируемости, то это уже вопрос оптимизации, а не дизайна.
Только вот дизайн в немалой степени определяет, насколько мы можем это реализовать. А тесты определяют их в гораздо большей степени, ввиду своего предельного формализма. Достоинство TDD оборачивается его недостатком. Диалектика, однака.
AVK>>Речь идет о TDD и о тестах TDD. При чем тут все тесты? G>Я говорю о всех тестах для конкретного unit.
Ага, доказывая тем рулезность TDD
G> Их может быть очень много чтобы за раз все написать.
И чего?
AVK>>Этого в TDD нет. Совсем. Ссылочку на определение я привел. G> Википедия теперь сичтается истиной?
То есть ты с определением в википедии не согласен? Приведи другое определение из какого нибудь внешнего по отношению к тебе источника.
G>Ну если считать истинным определение в википедии, то кроме "практика показывает" ничего ответить не могу.
Вот. Именно об этом я и писал. Написать кучу бла-бла, это завсегда, а как касаемся конкретики, так сразу проблемы в оппонентах.
G>Это примерно как о вкусе устриц рассуждать. Лучше всего это делать с тем кто их ест.
Синдром бакалавра, кажется? С чего ты взял, что я TDD не использовал? Так удобнее доказать, что ты прав?
P.S. Это уже анекдот напоминает — ты упорно, на любые возражения, вместо нормальных аргументов ищешь проблемы в собеседнике. Продолжай, этот топик будет прекрасной иллюстрацией.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
G>Прототип нужен не для дизайна, а для провеки требований и идей.
Предположим. Тогда на момент написания тестов TDD мы никакой конкретикой по прежнему не знаем, точной спецификации нет. Значит и тесты непонятно как писать.
G>Я в прототипах не парюсь и пишу логику в button_click, никаким дизайном там и не пахнет.
Я что то как то не уловил смысла этой фразы. Не мог бы ты поподробнее свою мысль изложить?
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Во-первых более половины критерием неформализуемы AVK>Разумеется.
G>>, для них не то что тестов написать, даже адекватную метрику придумать сложно. AVK>Именно.
Нельзя написать тесты для того, что неформализуемо и не выражается в коде.
А чего ты тогда хочешь доказать?
G>>Во-вторых при правльном применении AVK>Опять бла-бла-бла. Ты не мудри, ты пальцем покажи. http://blog.wekeroad.com/mvc-storefront/kona-2/
G>>А что касается быстродействия, потребялемой памяти и масштабируемости, то это уже вопрос оптимизации, а не дизайна. AVK>Только вот дизайн в немалой степени определяет, насколько мы можем это реализовать. А тесты определяют их в гораздо большей степени, ввиду своего предельного формализма. Достоинство TDD оборачивается его недостатком. Диалектика, однака.
А что, тесты — это нерушимая стена или часть ОС?
Если оптимизиация вызывает изменнеие дизайна, то надо переделать тесты.
AVK>То есть ты с определением в википедии не согласен? Приведи другое определение из какого нибудь внешнего по отношению к тебе источника.
Я уже давно выяснил, написанное в википедии про TDD\BDD\DDD\IoC и прочие буквосочетания имеет мало общего с реальностью. Написано может быть и правильно, но не то что нужно.
Поэтому предпочитаю смотреть код и смотреть как люди пишут этот код.
G>>Ну если считать истинным определение в википедии, то кроме "практика показывает" ничего ответить не могу. AVK>Вот. Именно об этом я и писал. Написать кучу бла-бла, это завсегда, а как касаемся конкретики, так сразу проблемы в оппонентах.
Какой конкретики?
Если хочешь — давай конкретные требования, я вполне конкретно могу показать как их сделать с помощью TDD, и даже могу показать что будет в случае небольших измненеий требований.
А то так дойдем до "конкретных" решений проблем мироздания с помощью TDD. Легко после этого будет TDD ругать.
G>>Это примерно как о вкусе устриц рассуждать. Лучше всего это делать с тем кто их ест. AVK>Синдром бакалавра, кажется? С чего ты взял, что я TDD не использовал? Так удобнее доказать, что ты прав?
А я не говорил что ты его не использовал, я лишь говорю что если мнение о TDD построено на википедии, то дальнейшее обсуждение бессмысленно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Прототип нужен не для дизайна, а для провеки требований и идей.
AVK>Предположим. Тогда на момент написания тестов TDD мы никакой конкретикой по прежнему не знаем, точной спецификации нет. Значит и тесты непонятно как писать.
И как в таких условиях вообще код писать или проектированием заниматься?
G>>Я в прототипах не парюсь и пишу логику в button_click, никаким дизайном там и не пахнет. AVK>Я что то как то не уловил смысла этой фразы. Не мог бы ты поподробнее свою мысль изложить?
Мысль в том что прототим делается не для дизайна, а для того чтобы более наглядно представить требования или идею, которую хочется реализаовать.
Прототип помогает избавиться от неопределенности и противоречивости в требованиях.
G>>>Ну в .NET и java есть статические типы, но именно в них TeDD находит такое широкое применнение. T>>Ты и с историей TeDD не знаком. Он же родом из Смолтока, Кент Бек (который экстремальное программирование) его автор. G>Отлично знаком. И что что родом из смолтока? все ООП родом из смолтока, правда на смолток нифига не похоже...
ОО растёт из Симулы. Даже Смолток.
T>>В .Net и Java отвратительная статическая типизация, это я тебе ответственно заявляю и здесь многие поддержат это моё мнение. G>Да и я поддержу.
T>>Неудивительно, что в них применяется метод из совсем уж слабых языков программирования. G>А вот тут не согласен. Тестирование и TDD вполне достойные методы сами по себе. G>Ты все пытаешься доказать что при хорошей системе типов они не нужны, но как-то неубедительно.
Нужно функциональное тестирование, а не интеграционное и ниже уровнями.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, gandjustas, Вы писали:
G>Нельзя написать тесты для того, что неформализуемо и не выражается в коде.
Об этом и речь.
G>А чего ты тогда хочешь доказать?
То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата.
G>>>Во-вторых при правльном применении AVK>>Опять бла-бла-бла. Ты не мудри, ты пальцем покажи. G>http://blog.wekeroad.com/mvc-storefront/kona-2/
Что я там должен увидеть?
G>Если оптимизиация вызывает изменнеие дизайна, то надо переделать тесты.
Курица или яйцо? Откуда взялись изначальные тесты?
AVK>>То есть ты с определением в википедии не согласен? Приведи другое определение из какого нибудь внешнего по отношению к тебе источника. G>Я уже давно выяснил, написанное в википедии про TDD\BDD\DDD\IoC и прочие буквосочетания имеет мало общего с реальностью. Написано может быть и правильно, но не то что нужно. G>Поэтому предпочитаю смотреть код и смотреть как люди пишут этот код.
Приведи другое определение из какого нибудь внешнего по отношению к тебе источника.
Если не можешь, так и скажи.
G>Какой конкретики?
Ответов на конкретные вопросы. Я тебе их уже много в этом топике задавал.
G>Если хочешь — давай конкретные требования
А если их нет, конкретных и формальных? Если у меня они есть, я и без тебя знаю, что да как. Наличие таких требований уже больше 50% решения задачи.
G>А я не говорил что ты его не использовал
Тогда к чему тирада про устриц? Ты кого имел в виду?
G>, я лишь говорю что если мнение о TDD построено на википедии
Нет, мое мнение не построено на википедии. Просто в википедии, на мой взгляд, вполне неплохое изложение идеи. И, уж извини, какой бы плохой википедия не была, я ей как то больше доверяю, чем твоим бездоказательным утверждениям, основанным на том, что ты где то что то непонятно что видел или читал. Да, на всякий случай — умные книжки про TDD читал, реальные проекты с его использованием видел, и даже сам применял. Так что больше не стоит про устриц или непонимание, ок?
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
AVK>>Предположим. Тогда на момент написания тестов TDD мы никакой конкретикой по прежнему не знаем, точной спецификации нет. Значит и тесты непонятно как писать. G>И как в таких условиях вообще код писать или проектированием заниматься?
А что, ты не смог бы? Обыкновенно — включаешь моск и вперед.
G>>>Я в прототипах не парюсь и пишу логику в button_click, никаким дизайном там и не пахнет. AVK>>Я что то как то не уловил смысла этой фразы. Не мог бы ты поподробнее свою мысль изложить? G>Мысль в том что прототим делается не для дизайна, а для того чтобы более наглядно представить требования или идею, которую хочется реализаовать.
Тогда возвращаемся к началу — если нет формальных требований, а есть лишь набор критериев и относительная важность каждого из них, как применять TDD? Формальные тесты уже, в немалой степени, определят дизайн решения на уровне контрактов юнитов. А у нас как раз и стоит задача разработки такого дизайна, а не чтобы тупо налопатить код в рамках готового дизайна.
G>Прототип помогает избавиться от неопределенности и противоречивости в требованиях.
Каким образом, интересно? Можно на конкретном примере?
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
. PEX тем и характерен, что тесты формирует по тестируемому коду, т.е., очевидно, после написания функционального кода.
