Привет всем.
Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD)
и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
В последнее время сталкиваюсь с большим колличеством советов обязательно использовать unit testing — проскакивает во многих подкастах .NET Rocks и Hanselminutes, но также
часто слышу, что это ерунда — с изменением кода необходимо менять тесты, трата времени и т.д.
(пример — Unit testing is teh suck, Urr.)
Хочется послушать людей, которые удачно применяли TDD или просто использовали Unit testing, а также тех, кто является его противником.
P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет? BIS>В последнее время сталкиваюсь с большим колличеством советов обязательно использовать unit testing — проскакивает во многих подкастах .NET Rocks и Hanselminutes, но также BIS>часто слышу, что это ерунда — с изменением кода необходимо менять тесты, трата времени и т.д. BIS>(пример — Unit testing is teh suck, Urr.) BIS>Хочется послушать людей, которые удачно применяли TDD или просто использовали Unit testing, а также тех, кто является его противником.
BIS>P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает
Юнит-тесты применяю, ТДД — нет.
Юнит-тесты в мней практике во многих случаях доказали свою полезность.
Стандартный сценарий, в котором они полезны — ты разрабатываешь класс, естественно, как-то его тестируешь, понемножку класс обрастает функциональностью, ты его, естественно, рефакторишь и, естественно, не проверяешь, не сломалась ли старая функциональность, потому что ты ее уже тестировал.
Так вот когда ты с классом закончил и класс готов к коммиту, ты начинаешь писать тесты и вдруг обнаруживаешь, что работает не все, а только то, что ты тестил в последнее время. Заодно, когда ты концентрируешься на тестах, ты начинаешь писать тесты на всякие исключительные ситуациии и прочие граничные случаи, и тоже иногда оказывается, что какой-то конкретный случай ты не обрабатываешь.
Для рефакторинга юнит-тесты вообще вещи незаменимая, потому что рефакторинг по определению — это изменение когда без изменения функциональности, и юнит-тесты для контроля этого аспекта подходят как нельзя лучше.
Плюс юнит-тесты заставляют делать много маленьких независимых классов, потому что универсальный всемогутер осмысленному тестированию практически не поддается — количество тестов, которые нужно написать, растет экспоненциально с каждой лишней мелкой функциональностью.
А когда у тебя есть маленькие простые классы, то, во-первых, тесты для них пишутся элементарно и написать их неправильно затруднительно, а во-вторых, у простых классов гораздо больше шансов быть переиспользованными без переписывания вообще (и как следствие — без переписывания тестов): изменится лишь код, компонующий эти классы вместе; и в-третьих, писать тесты на скомпонованный класс, основываясь на том, что более мелкие компоненты уже оттестированы своими тестами, гораздо проще.
А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода.
BokiyIS wrote:
> Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование > (а возможно и вообще TDD)
Да, если это только возможно.
> и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
Да. 100%
> часто слышу, что это ерунда — с изменением кода необходимо менять тесты, > трата времени и т.д.
0) не во всех случаях изменения кода меняются тесты. Т.е. это просто неправда.
Есть случаи, когда меняется, есть — когда не меняется. Обычно, если интерфейс
и семантика модуля не меняется, то не меняются и тесты.
1) Даже когда тесты надо переписывать, иного способа надёжного тестирования
нет.
J>Для рефакторинга юнит-тесты вообще вещи незаменимая, потому что рефакторинг по определению — это изменение когда без изменения функциональности, и юнит-тесты для контроля этого аспекта подходят как нельзя лучше.
Смотря на какую функциональность ты смотришь.
Если приложения в целом (или подсистемы в целом), то юнит-тесты бесполезны. Если рефакторинг отдельных классов, то этот рефакторинг мало полезен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
1) TDD не применяю, хотя в свое время разбирался что это такое
2) Unit тестирование скорее не применяю, чем применяю
3) Автоматизированное (при помощи unit фреймворков) функциональное тестирование применяю регулярно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
Unit-тестирование без TDD чаще всего бесполезное занятие.
BIS>В последнее время сталкиваюсь с большим колличеством советов обязательно использовать unit testing — проскакивает во многих подкастах .NET Rocks и Hanselminutes, но также BIS>часто слышу, что это ерунда — с изменением кода необходимо менять тесты, трата времени и т.д. BIS>(пример — Unit testing is teh suck, Urr.)
Это от того что люди не понимают зачем пишутся тесты.
BIS>Хочется послушать людей, которые удачно применяли TDD или просто использовали Unit testing, а также тех, кто является его противником.
Я более-менее удачно применяю TDD.
Я не буду писать плюсы-минусы, влом Но отмечу один момент: представьте что у вас проект в несколько сот тысяч строк кода и вам надо сделать пусть даже небольшой рефакторинг? Вообще я заметил что необходимость некоторых вещей понимается только на средних и больших проектах.
Здравствуйте, MozgC, Вы писали:
MC>Я не буду писать плюсы-минусы, влом Но отмечу один момент: представьте что у вас проект в несколько сот тысяч строк кода и вам надо сделать пусть даже небольшой рефакторинг? Вообще я заметил что необходимость некоторых вещей понимается только на средних и больших проектах.
Или на коде, к которому лет пять никто не притрагивался.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
Ответ банальный: зависит от того, что за задача. Я для себя отметил, что если идет разработка самого алгоритма (нетривиального), то Unit-тесты в обычном варианте не самый удачный вариант. Главным образом по следующим причинам: (1) нетривиальный алгоритм тяжело разбить на составные части, каждую из которых легко протестировать (2) часто все части работают по отдельности правильно, но существует расклад, который рушит больше взаимодействие этих частей (3) ошибка проявляется не нетривиальных сущностях (4) алгоритм в разработке часто меняется, мало фиксированных частей.
В этом случае более полезен набор тестовых задач, на которые натравливается алгоритм, и на выходе % решенных задач, затраченное время и т. п.
Здравствуйте, Mystic, Вы писали:
M>Ответ банальный: зависит от того, что за задача. Я для себя отметил, что если идет разработка самого алгоритма (нетривиального), то Unit-тесты в обычном варианте не самый удачный вариант. Главным образом по следующим причинам: (1) нетривиальный алгоритм тяжело разбить на составные части, каждую из которых легко протестировать (2) часто все части работают по отдельности правильно, но существует расклад, который рушит больше взаимодействие этих частей (3) ошибка проявляется не нетривиальных сущностях (4) алгоритм в разработке часто меняется, мало фиксированных частей.
M>В этом случае более полезен набор тестовых задач, на которые натравливается алгоритм, и на выходе % решенных задач, затраченное время и т. п.
В этом случае цельный алгоритм (пусть это будет какой-нибудь поиск на графах) можно принять за юнит. Влезать в него и тестировать каждый оператор правда нет смысла.
А использовать нетривиальные алгоритмы не прогнав по ним набор тестовых задачь — вообще ахтунг!
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>Unit-тестирование без TDD чаще всего бесполезное занятие.
FR>Очень даже полезное
А потом появляются темы типа "я написал 150 unit-тестов, для своего класса, потом поменял в классе одну строчку и мне пришлось больше половины тестов переписать".
Писать unit-тесты, для кода который не предназачался для такого тестирования очень тяжко. Обычно отдельно класс или функцию протестировать не получается, прходится тестировать большой связный кусок кода или использовать тулзы типа TypeMock.
G>А потом появляются темы типа "я написал 150 unit-тестов, для своего класса, потом поменял в классе одну строчку и мне пришлось больше половины тестов переписать".
G>Писать unit-тесты, для кода который не предназачался для такого тестирования очень тяжко. Обычно отдельно класс или функцию протестировать не получается, прходится тестировать большой связный кусок кода или использовать тулзы типа TypeMock.
А не мог ли бы ты описать примерную твою предметную область и типичные сроки сдачи чего-либо?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>А потом появляются темы типа "я написал 150 unit-тестов, для своего класса, потом поменял в классе одну строчку и мне пришлось больше половины тестов переписать".
G>>Писать unit-тесты, для кода который не предназачался для такого тестирования очень тяжко. Обычно отдельно класс или функцию протестировать не получается, прходится тестировать большой связный кусок кода или использовать тулзы типа TypeMock.
T>А не мог ли бы ты описать примерную твою предметную область и типичные сроки сдачи чего-либо?
Последнее чем занимался — веб приложения, в основном электронная коммерция, документооборот и все такое. Итерации короткие, неделя-две.
Здравствуйте, jazzer, Вы писали:
J>Плюс юнит-тесты заставляют делать много маленьких независимых классов, потому что универсальный всемогутер осмысленному тестированию практически не поддается — количество тестов, которые нужно написать, растет экспоненциально с каждой лишней мелкой функциональностью. J>А когда у тебя есть маленькие простые классы, то, во-первых, тесты для них пишутся элементарно и написать их неправильно затруднительно, а во-вторых, у простых классов гораздо больше шансов быть переиспользованными без переписывания вообще (и как следствие — без переписывания тестов): изменится лишь код, компонующий эти классы вместе; и в-третьих, писать тесты на скомпонованный класс, основываясь на том, что более мелкие компоненты уже оттестированы своими тестами, гораздо проще.
+1
J>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода.
Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал.
Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
S>В этом случае цельный алгоритм (пусть это будет какой-нибудь поиск на графах) можно принять за юнит.
Так и получается. Только UNIT-тестирование сводится к разработке внешнего приложения, которое читает последовательно файлы из парки, парсит их на предмет данных и результатов, данные загоняет в алгоритм и проверяет результат...
S>А использовать нетривиальные алгоритмы не прогнав по ним набор тестовых задачь — вообще ахтунг!
Не всегда эти тестовые задачи есть. Ну и бывает когда задачи есть, а ответов нету.
G>>>Unit-тестирование без TDD чаще всего бесполезное занятие.
FR>>Очень даже полезное
G>А потом появляются темы типа "я написал 150 unit-тестов, для своего класса, потом поменял в классе одну строчку и мне пришлось больше половины тестов переписать".
Люблю телепатов
G>Писать unit-тесты, для кода который не предназачался для такого тестирования очень тяжко. Обычно отдельно класс или функцию протестировать не получается, прходится тестировать большой связный кусок кода или использовать тулзы типа TypeMock.
Здравствуйте, thesz, Вы писали:
J>>Для рефакторинга юнит-тесты вообще вещи незаменимая, потому что рефакторинг по определению — это изменение когда без изменения функциональности, и юнит-тесты для контроля этого аспекта подходят как нельзя лучше.
T>Смотря на какую функциональность ты смотришь.
T>Если приложения в целом (или подсистемы в целом), то юнит-тесты бесполезны.
естественно, потому что приложение в целом — это не юнит, если это не приложение типа grep, конечно же.
Но приложение в целом собирается из кусков, и лучше, чтоб эти куски были оттестированы соответствующими юнит-тестами, чем держать пальцы крестиком на тему "надеюсь, что этот компонент в этих условиях не сглючит"
T>Если рефакторинг отдельных классов, то этот рефакторинг мало полезен.
Если у тебя есть класс А, который использует классы Б и В, а ты его рефакторишь на использование классов Г и Д (не говоря уже о микро-рефакторингах типа "вынести метод" и т.п.) — это вполне себе рефакторинг, и юнит-тесты тут очень в тему.
Здравствуйте, gandjustas, Вы писали:
J>>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода. G>Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал. G>Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
а как насчет того, что ты не учел 50 взаимосвязей, из-за который весь твой тестирующий код не имеет смысла, просто потому что, скажем, невозможно в заданном порядке сконструировать объекты, по каким угодно причинам?
Я несколько раз пробовал подступиться в ТДД, и каждый раз напарывался на это.
Я предпочитаю работать снизу вверх.
Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения.
И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами.
Естественно, с тестами.
И когда ты доходишь до момента, когда минимальные сущности уже не выделяются, оказывается, что собрать требуемую подсистему из готовых компонентов сравнительно просто и быстро, так что ты можешь более-менее свободно экспериментировать, и главное, что эти компоненты потому будут использоваться в других местах проекта, уже будучи оттестированными.
А ТДД в этом смысле — это немного наоборот, сверху вниз, потому что ты пишешь тесты сразу для подсистемы, и то, какая будет архитектура этой подсистемы, что в ней универсального и переиспользуемого, остается за скобками — главное ведь, чтоб тесты сходились...
Здравствуйте, jazzer, Вы писали:
J>Я предпочитаю работать снизу вверх. J>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>Естественно, с тестами.
J>А ТДД в этом смысле — это немного наоборот, сверху вниз
Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
J>>>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода. G>>Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал. G>>Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
J>а как насчет того, что ты не учел 50 взаимосвязей, из-за который весь твой тестирующий код не имеет смысла, просто потому что, скажем, невозможно в заданном порядке сконструировать объекты, по каким угодно причинам?
В какой момент их можно не учесть в таком количестве? Если сначала пишутся тесты, а потом код, то откуда возьмутся эти 50 взаимосвязей?
J>Я несколько раз пробовал подступиться в ТДД, и каждый раз напарывался на это.
Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают.
J>Я предпочитаю работать снизу вверх. J>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>Естественно, с тестами.
Отлично, что на данном этапе мешает написать сначала тесты?
J>И когда ты доходишь до момента, когда минимальные сущности уже не выделяются, оказывается, что собрать требуемую подсистему из готовых компонентов сравнительно просто и быстро, так что ты можешь более-менее свободно экспериментировать, и главное, что эти компоненты потому будут использоваться в других местах проекта, уже будучи оттестированными.
J>А ТДД в этом смысле — это немного наоборот, сверху вниз, потому что ты пишешь тесты сразу для подсистемы, и то, какая будет архитектура этой подсистемы, что в ней универсального и переиспользуемого, остается за скобками — главное ведь, чтоб тесты сходились...
Это сильно догматичный TDD подход, который любят толкать агилисты. Есть более прагматичный подход, когда архитектура и высокоуровневы дизайн выполняются как обычно — определяются интерфесы, придумываются слои, итд. А детальный дизайн выполняется с помощью TDD.
Здравствуйте, Mystic, Вы писали:
M>Так и получается. Только UNIT-тестирование сводится к разработке внешнего приложения, которое читает последовательно файлы из парки, парсит их на предмет данных и результатов, данные загоняет в алгоритм и проверяет результат...
Это неправильный подход. При правильном подходе тест кормит алгоритму (через моки/стабы) некий заранее сформированный инпут, и затем сравнивает результат с тем, который должен быть. Причём тесты пишутся идеально просто в случае, если используется IoC, ибо тогда ничего не стоит вместо компонента, "который читает последовательно файлы из папки" (С), подсунуть мок, который вернёт то, что надо — да хоть захардкоженный прямо в тесте инпут. Алгоритмы — это именно то, что в 99.(9)% случаев отлично поддаётся юнит-тестированию.
Mystic пишет:
> Так и получается. Только UNIT-тестирование сводится к разработке > внешнего приложения, которое читает последовательно файлы из парки, > парсит их на предмет данных и результатов, данные загоняет в алгоритм и > проверяет результат...
Это уже не Unit-тестирование.
Это — просто тестирование. Unit-тест — это когда разбирают программу
по винтикам, и каждый винтик проверяют. Потом собирают. Это не значит,
что три собранных винтика проверить -- это не Unit-тест. Но ТОЛЬКО всё вместе
тестировать — это простое тестирование, регрессионное, функциональное и т.п.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, gandjustas, Вы писали:
J>>>>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода. G>>>Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал. G>>>Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
J>>а как насчет того, что ты не учел 50 взаимосвязей, из-за который весь твой тестирующий код не имеет смысла, просто потому что, скажем, невозможно в заданном порядке сконструировать объекты, по каким угодно причинам? G>В какой момент их можно не учесть в таком количестве? Если сначала пишутся тесты, а потом код, то откуда возьмутся эти 50 взаимосвязей?
При написании собственно кода
Невозможно все учесть до того, как код написан.
Вдруг выяснится, что в конкретный метод надо передавать еще пару параметров, и что надо еще пару объектов создать для правильного окружения, и т.д. и т.п.
Хотя 50 — это я, наверное, загнул
J>>Я несколько раз пробовал подступиться в ТДД, и каждый раз напарывался на это. G>Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают.
Ну если эти контейнеры только для тестов — то да.
А так — выбор контейнера все-таки должен определяться задачей, а не нуждами тестов
В любом случае, это не принципиальный момент, просто неудобство, которое приводит к переписыванию теста, если он был написан слишком рано.
J>>Я предпочитаю работать снизу вверх. J>>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>>Естественно, с тестами. G>Отлично, что на данном этапе мешает написать сначала тесты?
Да ничего не мешает. Можешь считать это моими личными предпочтениями.
Я предпочитаю сначала вчерне набросать рабочий код, который что-то делает в более-менее реальном окружении (в процессе этого может много чего поменяться по сравнению с первоначальной идеей, просто потому что какие-то новые идеи придут в процессе, например, поменяется интерфейс или твой модуль распадется еще на пару модулей), потом, когда архитектура и интерфейс устоялись, написать к нему тесты и уже с их помощью отполировать код для состояния, когда можно коммитить.
J>>И когда ты доходишь до момента, когда минимальные сущности уже не выделяются, оказывается, что собрать требуемую подсистему из готовых компонентов сравнительно просто и быстро, так что ты можешь более-менее свободно экспериментировать, и главное, что эти компоненты потому будут использоваться в других местах проекта, уже будучи оттестированными.
J>>А ТДД в этом смысле — это немного наоборот, сверху вниз, потому что ты пишешь тесты сразу для подсистемы, и то, какая будет архитектура этой подсистемы, что в ней универсального и переиспользуемого, остается за скобками — главное ведь, чтоб тесты сходились... G>Это сильно догматичный TDD подход, который любят толкать агилисты. Есть более прагматичный подход, когда архитектура и высокоуровневы дизайн выполняются как обычно — определяются интерфесы, придумываются слои, итд. А детальный дизайн выполняется с помощью TDD.
В такой формулировке, и с оговоркой выше — согласен.
Перефразируя Эйнштейна, тесты должны писаться настолько рано, насколько это возможно, но не раньше.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, jazzer, Вы писали:
J>>Я предпочитаю работать снизу вверх. J>>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>>Естественно, с тестами.
J>>А ТДД в этом смысле — это немного наоборот, сверху вниз S>Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, samius, Вы писали:
S>>Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
КБ>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
А что заставляет начинать с тестов подсистем, а не с тестов компонент?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, jazzer, Вы писали:
J>>>Здравствуйте, gandjustas, Вы писали:
J>>>>>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода. G>>>>Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал. G>>>>Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
J>>>а как насчет того, что ты не учел 50 взаимосвязей, из-за который весь твой тестирующий код не имеет смысла, просто потому что, скажем, невозможно в заданном порядке сконструировать объекты, по каким угодно причинам? G>>В какой момент их можно не учесть в таком количестве? Если сначала пишутся тесты, а потом код, то откуда возьмутся эти 50 взаимосвязей? J>При написании собственно кода J>Невозможно все учесть до того, как код написан. J>Вдруг выяснится, что в конкретный метод надо передавать еще пару параметров, и что надо еще пару объектов создать для правильного окружения, и т.д. и т.п.
Тесты как раз позволяют выявить такое до написания код.
J>>>Я несколько раз пробовал подступиться в ТДД, и каждый раз напарывался на это. G>>Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают. J>Ну если эти контейнеры только для тестов — то да.
Наоборот, контейнер в программе, в тестах он не нужен. Все зависимоти подсовываются через конструктор. Их редко бывает больше 5 штук.
J>В любом случае, это не принципиальный момент, просто неудобство, которое приводит к переписыванию теста, если он был написан слишком рано.
Тесты до кода позволяют уменьшить количество переписываний кода в процессе разработки функционала.
Здравствуйте, gandjustas, Вы писали:
G>Тесты как раз позволяют выявить такое до написания код. G>Тесты до кода позволяют уменьшить количество переписываний кода в процессе разработки функционала.
Ну, значит, мне не так везло. Для меня практика написания полного тест-сьюта для компонента до того, как у компонента появится что-то, кроме имени, частенько (но не всегда, конечно же) выливалось в "Гладко было на бумаге, да забыли про овраги, а по ним ходить".
G>>>Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают. J>>Ну если эти контейнеры только для тестов — то да. G>Наоборот, контейнер в программе, в тестах он не нужен. Все зависимоти подсовываются через конструктор. Их редко бывает больше 5 штук.
В таком случае это уже к вопросу об общей архитектуре приложения, которая сейчас немножко оффтопик.
Скажем так: если приложение сделано с применением IoC, то писать модульные тесты для его компонентов легче.
Не флейма ради, просто на полях:
Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Тесты как раз позволяют выявить такое до написания код. G>>Тесты до кода позволяют уменьшить количество переписываний кода в процессе разработки функционала. J>Ну, значит, мне не так везло. Для меня практика написания полного тест-сьюта для компонента до того, как у компонента появится что-то, кроме имени, частенько (но не всегда, конечно же) выливалось в "Гладко было на бумаге, да забыли про овраги, а по ним ходить".
Так и есть. Полный тест-сьют и не требуется для начала работы над компонентом. Цикл красное-зеленое-рефакторим итерируется по одному, максимум двумя тестам, никогда итерация не равна полному тест-сьюту для компонента.
Здравствуйте, BokiyIS, Вы писали:
BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование
Да, обязательно! Периодически вычисляется coverage (процент покрытия кода тестами),
и по его результатам для классов с низким покрытием пишутся дополнительные тесты.
Плюс при code review любой из инспекторов вправе потребовать написать юнит-тест для
кода, если есть подозрение, что там возможны проблемы.
Как показывает практика, даже для примитивнейшего кода из трёх строк юнит-тесты могут выявить скрытые грабли.
Вот, к примеру, из недавнего: http://www.rsdn.ru/forum/message/3299673.aspx
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Здравствуйте, samius, Вы писали:
S>>>Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
КБ>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
S>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, samius, Вы писали:
S>>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
КБ>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
Мягко выражаясь, не верю. Можно ссылку?
Вообще, раз на то пошло, то разбивка на компоненты может происходить как минимум во время рефакторинга, который делается в конце очередной итерации. А рефакторинг в конце итерации делается сам по себе без всяких требований тестов.
Здравствуйте, Константин Б., Вы писали:
КБ>>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
S>>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
КБ>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
Вернитесь на землю — написанием тестов на систему в целом TDD не занимается. тесты на новые микрокомпоненты пишутся глядя на проект новых компонент. а он в свою очередь взялся из нового use case. Те проектрировать и вообще думать не запрещено
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, Константин Б., Вы писали:
КБ>>>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
S>>>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
КБ>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
SD>Вернитесь на землю — написанием тестов на систему в целом TDD не занимается. тесты на новые микрокомпоненты пишутся глядя на проект новых компонент. а он в свою очередь взялся из нового use case. Те проектрировать и вообще думать не запрещено
Ну не совсем. Последовательность примерно такая. Use case на подсистему -> тест на подсистему -> use case на компонент -> тест на компонент.
Написать тест на компонент, до теста на подсистему в рамках TDD не получается.
Здравствуйте, samius, Вы писали:
КБ>>Здравствуйте, samius, Вы писали: S>>>А что заставляет начинать с тестов подсистем, а не с тестов компонент? КБ>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены. S>Мягко выражаясь, не верю. Можно ссылку?
Не верите во что?
S>Вообще, раз на то пошло, то разбивка на компоненты может происходить как минимум во время рефакторинга, который делается в конце очередной итерации. А рефакторинг в конце итерации делается сам по себе без всяких требований тестов.
Ну это понятно. Непонятно в какой момент времени появятся тесты на компоненты.
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
ИМХО стоит. Но как и все в этом мире, юнит тесты нужно применять с головой. Статей, о том, какие юнит тесты и TDD клевые и прекрасные предостаточно, а повторятся не хочется. Так что я просто постараюсь разобрать типичные ошибки начинающих. Если что, я сам далеко не гуру в тестировании, и все нижесказанное лишь ИМХО.
Rage more
Неофиты, зачастую, считают, что чем больше тестов, тем лучше. Они радостно пишут тесты на каждый метод, включая приватные, а затем ноют, когда им приходится тесты менять. Между тем, далеко не все имеет смысл покрывать юнит тестами. Что именно стоит покрывать тестами подскажет опыт. Например, в одном банковском проекте (J2EE), в котором я участвовал, честными юнит тесами были покрыты лишь десяток классов для работы с валютой. Все остальное замечательно проверялось другими видами тестов, включая ручные. Текущий проект, high-load приложение на Java покрыто тестами процентов на 20. С другой стороны, в одном из моих проектов на Ruby on Rails модель покрыта тестами полностью, а контроллеры на 9/10. Другая моя библиотечка на Ruby тоже покрыта тестами полностью. Разница от того, что Ruby достаточно лаконичный язык, и принцип DRY соблюдается достаточно строго.
Что не имеет смысла покрывать юнит-тестами? Методы, ошибки в которых легко отлавливаются и еще легче исправляются. Это делегаты, перекладвания данных туда-сюда, тривиальная логика, которая и так будет высокоуровневыми тестами. Не всегда имеет смысл покрывать юнит тестами места, подверженные частыми изменениям. В типичном database editor такого кода чуть менее 100%.
Что имеет смысл покрывать юнит-тестами? Места на границах спецификаций, крайние и экстремальные случаи, ядро, сложные алгоритмы, утилитарные классы, хелперы общего назначения и т.п. Ошибки в таких местах имееют неприятное свойство вылезать уже на живой системе и интерферировать между собой приводя к непредсказуемым последствиям.
Think before
Когда мы начинаем писать код, нам чаще всего не известно о его клиентах. У нас есть в голове некоторое представление о них, но оно почти всегда неправильное. Юнит тесты хороши, как попытка поставить себя на место клиента и посмотреть насколько хорош наш интерфейс с его точки зрения. Вопрос, что писать сперва, тесты или код, лишен смысла. Сперва думать, а потом -- неважно. Если думать не получается, TTD может помочь направить мысли в правильную сторону. Если мысли и так текут правильно, нафига этот костыль?
Думать заранее полезно. При удачном предварительном проектировании, интерфейсы не менются годами. Например, год назад, я написал один небольшой модуль и полностью покрыл его тестами. С тех пор его интерфейс только расширялся, что не достовляло никаких хлопот с поддержкой тестов в актуальном состоянии. С другой стороны, при разработке интерфейс этого модуля неслабо колбасило. TDD сокращает процесс релаксации, но не устраняет его полностью.
Difficult case
Не всегда окружающий нас мир прост. Бывают сложные вещи, такие как эвристические алгоритмы, протокол Z39.50 или настройка почтового сервера под Linux. Сложные алгоритмы, это первые кандидаты на юнит тестирование. Их код плохо читается, а ошибки в них незаметны и болезненны. Я даже знаю историю, о том, как одна ошибка в алгоритме привела к банкротству компании.
Юнит-тесты побуждают к изоляции сложных алгоритмов, что положительно сказывает на связности системы. Если бы не они, никто бы не заморачивался изоляцией алгоритмов, которая почти всегда нетривиальна. Для любого, даже самого сложного, алгоритма всегда можно предположить, чего ожидать на выходе для заданного входа. Часто, я прямо в тесте запускаю алгоритм с разными входами и если они не соответствуют ожидаемым, разбираюсь почему. Возможно это ошибка, а может алгоритм не так хорош. В любом случае, после того как отладка закончена, поведение алгоритма фиксируется юнит тестом. Если алгоритм по своей природе нечеткий, не обязательно даже не сравнивать выход с фиксированными значениями. Можно сравнивать выходы между собой. Или искать инварианты. Возможностей масса.
Silver bullet
Юнит тесты не панацея. Небольшой ценой за написание и поддержку тестов они помогают избежать злокозненных багов. Если получается, нет причин их не писать. Если не выходит, нужно либо учиться проектировать устойчивый к тестированию код либо забить и не мучаться. Существуют и другие способы борьбы с ошибками.
Естествено это не касается методологий, в которых TTD неотъемлемая часть, например eXtreme Programming. Если вы используете XP, ничего не поделаешь, писать тесты придется, иначе XP перестанет работать.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, samius, Вы писали:
КБ>>>Здравствуйте, samius, Вы писали:
КБ>>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены. S>>Мягко выражаясь, не верю. Можно ссылку?
КБ>Не верите во что?
в выделенное
КБ>Ну это понятно. Непонятно в какой момент времени появятся тесты на компоненты.
Тут я согласен с SleepyDrago
Здравствуйте, BokiyIS, Вы писали:
BIS>P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает
Давненько была то такая тема.. я там даже отметился — http://rsdn.ru/Forum/Message.aspx?mid=2116090&only=1
Приятно что теперь отклик на подобную тему в форуме получился гоораздо больше
BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
Я считаю, что я гораздо продуктивнее когда пишу юнит тесты, чем без них. Даже на коротких задачах, в средних проектах.
BIS>Хочется послушать людей, которые удачно применяли TDD или просто использовали Unit testing, а также тех, кто является его противником.
Буквально месяц назад, я вынужден был взятся за функционал, размазаный по коду user space приложения и драйвера, на который перед этим
два разработчика потратили 4 дня, и в результате, родили нечто неполноценное и рандомайзно глючное. За 8 часов рабочего я изучил тестовый
фреймворк(CFix классная штука), наткнулся на все глюки возникновение которых растянуло элементарную задачу на 8 человекодней. И буквально
за полчаса после 18-00 заставил работать это все как часы.
Любишь ночевать на работе — не пиши тесты.
BIS>(а возможно и вообще TDD)
Скорее я делаю так:
Пишу небольшое ядро, изучаю предметную область, апи, особенности фреймворкаПишу тестыМодифицирую свою реализацию, делаю ее удобной для использованияНарашиваю функционал
-- Главное про деструктор копирования не забыть --
T>>А не мог ли бы ты описать примерную твою предметную область и типичные сроки сдачи чего-либо?
E>Эта информация бесполезна без информации о масштабе зарплаты по отношению к среднему уровню в данной предметной области в данном регионе.
Нененене. Это уже многое прояснит.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>А не мог ли бы ты описать примерную твою предметную область и типичные сроки сдачи чего-либо? G>Последнее чем занимался — веб приложения, в основном электронная коммерция, документооборот и все такое. Итерации короткие, неделя-две.
Понятно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Константин Б., Вы писали:
КБ>>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
SD>>Вернитесь на землю — написанием тестов на систему в целом TDD не занимается. тесты на новые микрокомпоненты пишутся глядя на проект новых компонент. а он в свою очередь взялся из нового use case. Те проектировать и вообще думать не запрещено
КБ>Ну не совсем. Последовательность примерно такая. Use case на подсистему -> тест на подсистему -> use case на компонент -> тест на компонент.
КБ>Написать тест на компонент, до теста на подсистему в рамках TDD не получается.
Как бы это объяснить. use case на систему. без всяких "под". да qa люди сразу планируют тест на систему для этого use case, но он не наш — не unit. И соответственно конфликта нет, как нет долговисящего красного uber теста.
А программисты используют свои маленькие тесты в своих целях. Как говорил человек, у которого я многому старался научиться, тесты нужны чтобы успеть вовремя. То есть они не цель, а средство достижения цели. Удачи!
Здравствуйте, Константин Б., Вы писали:
КБ>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
А они покажут, ты не переживай. Написать unit test для класса в несколько килострок кода — задача весьма нетривиальная и противная, поэтому его захочется разбить на классы помельче уже на этом этапе. И это хорошо, т.к. написать тот же тест после того, как будет написан этот самый "класс в несколько килострок" — эта задача может перейти вообще в разряд "mission imposible".
Опа, а что это такая благодарная тема и до сих пор не в КСВ?%)
Что-то никто не пишет о ассертах/встроенных проверках. По теме: зависит от проекта. Допустим в воспомогательных фреймворках (ака костыли) мегарулят контракты (самописные, ждём fw 4). Естественно, они ни разу не отменяют юнит-тестов, но привычка явно проверять принимаемые аргументы/проверять состояние в сложных алгоритмах нехило снижает уровень ошибок.
Используется примерно так (специально нашёл метод с избыточными проверками):
public static string ChangeExtension(string tokenValue, string newExtension)
{
Code.NotNull(newExtension, "newExtension");
Code.GreaterThanOrEqual(tokenValue.Length, "tokenValue.Length", 2);
Code.AssertArgument(
ContainsOnlyValidChars(newExtension), "newExtension",
@"Extension should not contain any of invalid chars.");
Code.AssertArgument(
newExtension.LastIndexOf(Dot) == 0, "newExtension",
@"Extension should starts with dot char ('.') and should not contain dots at any another position.");
return GetNameWithoutExtension(tokenValue) + newExtension;
}
В качестве бонуса получается централизованно обрабатывать нарушение утверждений (допустим делать Debugger.Break() перед throw/трейсить etc).
Ну а если есть регулярные интеграционные тесты + code review после каждого изменения, то юнит-тесты занимаются именно тем, чем и должны — отловом косяков в нетривиальном коде.
public static string ChangeExtension(string tokenValue, string newExtension)
{
Code.NotNull(newExtension, "newExtension");
Code.GreaterThanOrEqual(newExtension.Length, "newExtension.Length", 2);
Code.AssertArgument(
ContainsOnlyValidChars(newExtension), "newExtension",
@"Extension should not contain any of invalid chars.");
Code.AssertArgument(
newExtension.LastIndexOf(Dot) == 0, "newExtension",
@"Extension should starts with dot char ('.') and should not contain dots at any another position.");
return GetNameWithoutExtension(tokenValue) + newExtension;
}
Это кстати к вопросу о покрытии тестами юнит-тестов
Увы. Некоторые участники все еще in business. Могут обидеться. С другой стороны, в честь пятницы, могу рассказать сказку, по мотивам. Предметраня область изменена, действующие лица заретушированны. Все равно такое могло произойти с кем угодно.
Сказ о смертельном баге
Жила-была одна контора, которая делала, скажем движки для веб-почты. Но сама их не особенно использовала, а продавала кому понадобятся. И вот подошел к ней как-то на ярмарке один стартап и говорит:
–- Хочу движок почтовый, да не простой, а кастомный.
-- Любой каприз за ваши деньги, -- отвечает контора.
Тот продолжает:
-- Простых движков ко всему интернету натыкано, как репьев в огороде. А мы хотим веб-почту для публичных людей организовать. Певцов, политиков, актеров, ну вы поняли. Им столько почты приходит, что они ей пользоваться уже не могут.
Мы, говорит, тут уже все продумали. И как начнет требования перечислять, только знай, записывай. И под нагрузкой сервер падать не должен, а нагрузка немалая, а в пике и того больше. И отдельный интерфейс нужен для специально обученной девочки-секретаря. И свистелки-дуделки разнообразные. А главное, попросил он фичу-мегафичу. Еще не придумал какую. Ну например, чтоб одинаковые письма в кучи группировались. А что, полезно. Скажем, напечатает таблоид о помолвке 15 летней певички с 50-летним бизнесменом, так половина почты про это. Согласовали они тербования со сроками, да спустили задачу программистам. Ну а те, не долго думая требуемое и выпилили. А в качестве фичи-мегафичи прикрутили... ну скажем Байесовский классификатор.
Стартап на получившийсв движок посмотрел, интерфейс пощупал, в дуделки подудел да и остался доволен. И начал он свой проект раскручивать, а особенно упирал на эту уникальную фичу, которой ни у кого больше нет. Действительно, тем у кого меньше 100 писем в день и без нее жить легко. А прочие или сами фильры настраивают, или секретаря держат. Вот только в фиче-менафиче оказалась бага-мегабага. То важное письмо с предложением зарубежных гастролей среди фанспама спрячет. То плохие стихи в важное пропихнет. В общем, как-то не вкатила эта фича пользователям. Другие свистелки-дуделки не особенно интересны были. Gmail тоже от нагрузки не падает, свистелками не обделен, да и интерфейс имеет понятный среднему барабанщику. Зато за него платить не нужно. В общем, через полгода стартап закрылся. А еще через полгода при ревью кода по поводу фикса очередного бага кто-то обнаружил в что мегафича никогда и не работала нормально. И ошибка-то была банальная: то ли плюс, вместо минуса, то ли не на тот коэффициент умножили при нормировке. А что приемочные тесты проходили, так они синтетические и не особо тщательные.
Может, конечно, сказать, что не в баге дело, просто идея не пошла. Ну так на то это и сказка.
Здравствуйте, Sinix, Вы писали:
S>Что-то никто не пишет о ассертах/встроенных проверках. По теме: зависит от проекта. Допустим в воспомогательных фреймворках (ака костыли) мегарулят контракты (самописные, ждём fw 4). Естественно, они ни разу не отменяют юнит-тестов, но привычка явно проверять принимаемые аргументы/проверять состояние в сложных алгоритмах нехило снижает уровень ошибок.
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем.
BIS>P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает
Еще интереснее увидеть где-то структуру кода и сам исходный код РЕАЛЬНЫХ лучше коммерческих проектов где юнит тесты используються.
Здравствуйте, assad, Вы писали:
A>Здравствуйте, BokiyIS, Вы писали:
BIS>>Привет всем.
BIS>>P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает A>Еще интереснее увидеть где-то структуру кода и сам исходный код РЕАЛЬНЫХ лучше коммерческих проектов где юнит тесты используються.
Django покатит? Оупенсорс правда(под коммерческим подразумевается закрытый или приносящий деньги?). Вот пример (доктесты вроде как тоже под юниттесты катят). Coverage пока вроде 54.4%, но растёт.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Константин Б., Вы писали:
КБ>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
П>А они покажут, ты не переживай. Написать unit test для класса в несколько килострок кода — задача весьма нетривиальная и противная, поэтому его захочется разбить на классы помельче уже на этом этапе. И это хорошо, т.к. написать тот же тест после того, как будет написан этот самый "класс в несколько килострок" — эта задача может перейти вообще в разряд "mission imposible".
Мы все еще про TDD? Откуда при TDD взялся класс на несколько килострок без юнит-теста?
Здравствуйте, Константин Б., Вы писали:
КБ>Мы все еще про TDD?
Да
КБ>Откуда при TDD взялся класс на несколько килострок без юнит-теста?
А класса как такового еще нет, есть функционал, для которого надо написать код в несколько килострок. При обычном подходе есть далеко не нулевая вероятность, что кодер Вася впихнет этот код в один класс (поленится, поторопится к срокам или он просто потомственный раздолбай), добьется видимой работоспособности, закоммитит и забудет, а разгребать эту помойку придется кодеру Пете где-нибудь через полгода, когда всплывет какой-нибудь баг в использующих её модулях или понадобится чуть-чуть изменить её поведение. При TDD же Васе с самого начала придется самому трахаться с тестами для этого кода, а следовательно: а) заранее думывать о том, как он будет использоваться "снаружи" и б) лично наблюдать все чередования красный-зеленый-красный, которые возникают в уже написанных им тестах при каждой его модификации. Соответственно, мысль "а не разбить ли это безобразие на что-нибудь попроще", по идее, должна его рано или поздно все-таки посетить.
Да у нас просто практика такая — крайне осторожно относиться к компонентам "не из коробки". Как правило один-два милых косяка вылазят. Например, memory leak у datetimepicker'a был. Ещё были ньюансы с unity к vs 2005 (2-я entlib, весенний какой-то месяц). Ещё (хронически) crystal reports. Так что нафиг-нафиг хвататься за модную штуку при наличии самописного и работающего в силу своей примитивности. И без того хватает косяков у штатных велосипедов.
Самое печальное — это покупные контролы. Снаружи конфетка, а как заглянешь рефлектором...
Pex кстати щупал. Занятная штука. Может даже поиспользуем как подвернётся возможность.
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свеч или нет?
В чистом виде — не применяю, т.к. система сложная и писать тест — всё равно, что пятикратно переписать саму систему.
TDD применимо к маленьким, чётко оговоренным библиотечкам — синус посчитать, выходные дни... Для любой мало-мальски сложной системы тестирующие модули — болото, засасывающее человекочасы и всё равно не дающее никакой гарантии качества.
Некие простенькие тесты нужны, но исключительно убедиться, что после изменений не сломались обычные операции.
? J>Вопрос не праздный — давно интересно как это делают умные люди ...
имхо никак — тк юнит-тест не может воспроизводить все возможные комбинации при работе потоков.
те. тест может проверять переходы-состояния для каждого из параллельных, но не вместе.
Здравствуйте, matumba, Вы писали:
BIS>>Привет всем. BIS>>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>>и какие мысли у вас есть на этот счет. Стоит ли игра свеч или нет?
M>В чистом виде — не применяю, т.к. система сложная и писать тест — всё равно, что пятикратно переписать саму систему.
M>TDD применимо к маленьким, чётко оговоренным библиотечкам — синус посчитать, выходные дни... Для любой мало-мальски сложной системы тестирующие модули — болото, засасывающее человекочасы и всё равно не дающее никакой гарантии качества. M>Некие простенькие тесты нужны, но исключительно убедиться, что после изменений не сломались обычные операции.
Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
А если это не так (т.е. код не разделен на "маленькие, чётко оговоренные библиотечки", потому что все от всего зависит), то это называется простым словом "спагетти".
Здравствуйте, jazzer, Вы писали:
M>>TDD применимо к маленьким, чётко оговоренным библиотечкам
J>Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать! Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее. Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить.
Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение".
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
M>>>TDD применимо к маленьким, чётко оговоренным библиотечкам
J>>Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
M>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать!
Неправда. Каждый кирпичик тестируется отдельно, особенно внимание уделяется тому как он обращается к другим кирпичикам (моки, контракты). А потом работает транзитивность:
Если A корректно работает и корректно вызывает B и B корректно работает и корректно вызывает C, то композиция A->B->C.
Правда тут есть одно НО: когда мы пишем тесты, то не можем покрыть всех вариантов, поэтому композиция в некоторых случаях может не работать.
Но с помощью интеграционных тестов вполне можно проверить что некоторая композиция работает корректно на наиболее вероятных входных данных.
M>Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее.
Это зачастую признак хренового кода.
M>Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить.
Такие случаи находятся за пределами компетенции юнит-тестов.
Если у вас есть состяние гонки, то его вообще очень сложно отловить тестами.
M>Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение".
TDD, это не тесты, TDD — методика дизайна кода, причем вполне хорошо работающая при детальном дизайне.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
M>>>TDD применимо к маленьким, чётко оговоренным библиотечкам
J>>Открою тайну: нормальные сложные системы состоят из "маленьких, чётко оговоренных библиотечек".
M>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе.
Золотые слова!
"Строительный блок" — это как раз по-английски и есть unit
И Unit Testing — это _только_ о тестировании этих самых блоков.
А то, что ты пытаешься притянуть практику тестирования блоков к тестированию системы в целом — это уже твои проблемы.
Потому что для тестирования системы в целом есть system tests, integration tests и т.д.
Если продолдать строительную тематику, то очевидно, что приемы и методики тестирования кирпичей и труб совершенно не применимы к тестированию построенного здания целиком.
Остальное скипнуто как не относящееся к юнит-тестированию.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Mystic, Вы писали:
M>>Так и получается. Только UNIT-тестирование сводится к разработке внешнего приложения, которое читает последовательно файлы из парки, парсит их на предмет данных и результатов, данные загоняет в алгоритм и проверяет результат...
K>Это неправильный подход. При правильном подходе тест кормит алгоритму (через моки/стабы) некий заранее сформированный инпут, и затем сравнивает результат с тем, который должен быть. Причём тесты пишутся идеально просто в случае, если используется IoC, ибо тогда ничего не стоит вместо компонента, "который читает последовательно файлы из папки" (С), подсунуть мок, который вернёт то, что надо — да хоть захардкоженный прямо в тесте инпут. Алгоритмы — это именно то, что в 99.(9)% случаев отлично поддаётся юнит-тестированию.
Во-первых, как заметили ниже, это уже не UNIT-тестирование. Во-вторых, я не вижу принципиальной разницы между моим и вашим способом. В третьих, этот метод хорош, когда есть результат, который должен быть. А если его нету?
M>>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать! G>Неправда. Каждый кирпичик тестируется отдельно...
Такой примитивный уровень не интересен. Плюс из моего исходного сообщения пропущены ключевые слова, читайте внимательно.
M>>Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее. G>Это зачастую признак хренового кода.
Если ваши задачи решают квадратные уравнения, это ещё не повод думать, будто всё на свете так легко поддаётся декомпозиции.
M>>Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить. G>Такие случаи находятся за пределами компетенции юнит-тестов.
Как уже сказал, другие примитивные случаи не интересны. А судя по крикам студентов "Как, вы не пишете тесты?!?!" начинаешь опасаться за здоровье программирующих — уж не идолопоклонничеством ли они занимаются.
M>>Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение". G>TDD, это не тесты, TDD — методика дизайна кода, причем вполне хорошо работающая при детальном дизайне.
Спускаться к лингвистическим дебрям — это да, признак умного и квалифицированного оппонента.
TDD — buzzword, хорошо работающее на примитивных задачах. Сложные задачи продумать до деталей нереально, а когда твердолобые таки начинают писать спеки раньше программы, получается тот самый "исторически сложившийся маразм" в архитектуре. Итеративность — вот ключ разработки. А в такой динамике извините, тесты отдыхают.
Здравствуйте, jazzer, Вы писали:
J>И Unit Testing — это _только_ о тестировании этих самых блоков.
J>А то, что ты пытаешься притянуть практику тестирования блоков к тестированию системы в целом — это уже твои проблемы.
Капитан Очевидность, вам действительно интересен этот метод? Тогда могу только поздравить, все открытия у вас ещё впереди.
J>Потому что для тестирования системы в целом есть system tests, integration tests и т.д.
Пока я слышу только крики про "юнит-тесты" и их неоценимую помощь. Можете начать новую тему: "А вы пишете system tests?"
J>Если продолдать строительную тематику, то очевидно, что приемы и методики тестирования кирпичей и труб совершенно не применимы к тестированию построенного здания целиком.
Как я уже откомментировал, подобный примитив не интересен. Здания — вот уровень, с которого можно что-то обсудить со знающими людьми.
Здравствуйте, matumba, Вы писали:
M>>>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать! G>>Неправда. Каждый кирпичик тестируется отдельно...
M>Такой примитивный уровень не интересен.
Так это и есть unit-testing
M>Плюс из моего исходного сообщения пропущены ключевые слова, читайте внимательно.
Я ничего не вырезал.
M>>>Более того, метафора "кирпичей" хороша только в статьях — на деле, взаимодействие и проникновение кода куда сложнее. G>>Это зачастую признак хренового кода. M>Если ваши задачи решают квадратные уравнения, это ещё не повод думать, будто всё на свете так легко поддаётся декомпозиции.
Если что-то сложно поддается декомпозиции, то это не повод не заниматься декомпозицией.
M>>>Если модуль А делает работу, Б её обновляет, при этом модуль В синхронно работает с А и Б, обрабатывая результаты обоих, я бы не стал на вашем месте бросаться это тестировать "юнит-тестами" — рискуете поседеть и всё равно ни черта не решить. G>>Такие случаи находятся за пределами компетенции юнит-тестов.
M>Как уже сказал, другие примитивные случаи не интересны. А судя по крикам студентов "Как, вы не пишете тесты?!?!" начинаешь опасаться за здоровье программирующих — уж не идолопоклонничеством ли они занимаются.
Тогда зачем ты тут пишешь? Тема о юнит-тестах, а тебе она не интересна и ты пишешь о чем-то своем.
M>>>Увлечение новым buzzword "TDD" — это ещё один манёвр известного "огонь и движение". G>>TDD, это не тесты, TDD — методика дизайна кода, причем вполне хорошо работающая при детальном дизайне. M>Спускаться к лингвистическим дебрям — это да, признак умного и квалифицированного оппонента.
Ты просто не понимаешь TDD.
M>TDD — buzzword, хорошо работающее на примитивных задачах. Сложные задачи продумать до деталей нереально, а когда твердолобые таки начинают писать спеки раньше программы, получается тот самый "исторически сложившийся маразм" в архитектуре. Итеративность — вот ключ разработки. А в такой динамике извините, тесты отдыхают.
Надо декомпозировать любую задачу до примитивных. если этого не делать тогда всегда найдутся проблемы в архитекторах, процессах, инструментах.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
J>>И Unit Testing — это _только_ о тестировании этих самых блоков.
J>>А то, что ты пытаешься притянуть практику тестирования блоков к тестированию системы в целом — это уже твои проблемы.
M>Капитан Очевидность, вам действительно интересен этот метод? Тогда могу только поздравить, все открытия у вас ещё впереди.
Какой именно метод? Твой (юнит-тесты для системы в целом) — неинтересен. Юнит-тестирование — интересно.
J>>Потому что для тестирования системы в целом есть system tests, integration tests и т.д.
M>Пока я слышу только крики про "юнит-тесты" и их неоценимую помощь. Можете начать новую тему: "А вы пишете system tests?"
Конечно же начни, кто-то мешает?
J>>Если продолдать строительную тематику, то очевидно, что приемы и методики тестирования кирпичей и труб совершенно не применимы к тестированию построенного здания целиком.
M>Как я уже откомментировал, подобный примитив не интересен. Здания — вот уровень, с которого можно что-то обсудить со знающими людьми.
Ради бога. Не лезьте тогда в тему, где обсуждается примитивный уровень.
Здравствуйте, FR, Вы писали:
FR>Можно попробовать по мотивам http://en.wikipedia.org/wiki/QuickCheck сформировать инварианты и гонять на случайных данных и множестве запусков.
И получится тест, который может выдавать разный результат в зависимости от фазы Луны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, matumba, Вы писали:
M>Jazzer, у меня тоже есть для вас сюрприз! "маленькие, чётко оговоренные библиотечки" — это СТРОИТЕЛЬНЫЕ БЛОКИ, ничего не значащие сами по себе. Будучи же собранные в систему, они и составляют ту сложную хренотень, которую не так просто протестировать!
"Та сложная хренотень", собранная из библиотечек, юнит-тестами не тестируется по определению. Для этого есть тесты интеграционные и функциональные. Вот только если "хренотень" изначально состоит из модулей, которые делают "фиг-знает-что" (потому что писались на коленке без юнит-тестов), то это уже, увы, не поможет.
AndrewVK,
FR>>Можно попробовать по мотивам http://en.wikipedia.org/wiki/QuickCheck сформировать инварианты и гонять на случайных данных и множестве запусков.
AVK>И получится тест, который может выдавать разный результат в зависимости от фазы Луны.
А почему? Для языков таких как Эрланг и Хаскелл сей тул зарекомендовал себя с самой лучшей сторны: Multicore programming in Erlang
G>>Ты просто не понимаешь TDD.
AVK>Вот что меня всегда радовало, так это то, что все разговоры о TDD всегда заканчиваются этим "аргументом". Ну еще книжки отправляют читать, бывает.
Хорошо ещё не классическим "Ты просто не умеешь их готовить!".
Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!" (читай: ну вы и _удаки!) Да, возвышать себя унижая других — это древнее умение.
Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
Здравствуйте, matumba, Вы писали:
G>>>Ты просто не понимаешь TDD.
AVK>>Вот что меня всегда радовало, так это то, что все разговоры о TDD всегда заканчиваются этим "аргументом". Ну еще книжки отправляют читать, бывает.
M> Хорошо ещё не классическим "Ты просто не умеешь их готовить!".
Не надоело бравировать своим непониманием?
M>Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!"
Да ты че?
А ты не думал что проверить корректность программы на динамическом языке можно только тестированием?
Не приуменьшай важность тестирования как такового. А также разберись что такое TDD.
M>(читай: ну вы и _удаки!)
Если хочешь — читай так.
M>Да, возвышать себя унижая других — это древнее умение.
Ты это отлично показываешь.
M>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
А с чего ты взял что "многопоточное" важнее тестирования?
M>> Хорошо ещё не классическим "Ты просто не умеешь их готовить!". G>Не надоело бравировать своим непониманием?
Читаем ещё раз: M>>Да, возвышать себя унижая других — это древнее умение.
TDD очевиден как котлета, ЧТО вы в нём хотите обсудить? Флейма уже на 10 страниц, но вы упорно с видом мудреца впариваете 2х2=4.
G>А ты не думал что проверить корректность программы на динамическом языке можно только тестированием?
Ну вот, теперь ещё и динамика... А прежде чем вообще начинать темы про TDD, вы не удосужились очертить ЗАДАЧИ, которые вы им успешно решаете?
Пока я только слышу общие (а значит общеприменимые) и удивительные по настырности советы "пишите тесты!".
Кстати, "динамические языки" — не такая большая ниша, так что пусть решают свои проблемы сами, без рекламы TDD.
G>Не приуменьшай важность тестирования как такового. А также разберись что такое TDD.
См про "2х2".
Никто тесты не отрицает, но выпячивать их как панацею — встречается буквально в каждой первой статье о TDD.
Что забавно, Джоэл (в своих 12 признаках) даже словом не обмолвился о TDD. Есть повод задуматься.
M>>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал. G>А с чего ты взял что "многопоточное" важнее тестирования?
Это твои слова (туповатый метод спора, согласись?). Тестирование ЛЮБОГО вида важно, каждое в своей задаче. Но раз мы пишем весьма сложные задачи, то тесты а-ля "правильное вычисление квадратного корня" просто примитив по ср. с задачами самой системы.
Лучший тестер по прежнему остаётся человек.
Здравствуйте, matumba, Вы писали:
M>>> Хорошо ещё не классическим "Ты просто не умеешь их готовить!". G>>Не надоело бравировать своим непониманием?
M>Читаем ещё раз: M>>Да, возвышать себя унижая других — это древнее умение. M>TDD очевиден как котлета, ЧТО вы в нём хотите обсудить? Флейма уже на 10 страниц, но вы упорно с видом мудреца впариваете 2х2=4.
Я уже все в этой теме обсудил, и это не я с видом мудреца доказываю что тесты неважны.
G>>А ты не думал что проверить корректность программы на динамическом языке можно только тестированием?
M>Ну вот, теперь ещё и динамика... А прежде чем вообще начинать темы про TDD, вы не удосужились очертить ЗАДАЧИ, которые вы им успешно решаете?
Задача для тестов одна — проверка корректности кода.
Есть случая когда тестирование излишне — когда коррекность проверяется статически — с помощью системы типов или DbC.
Есть случаи, когда проверка корректности программы недетерминирована — такое возникает с асинхроных системах, в таком случае тесты неочень эффективны.
M>Пока я только слышу общие (а значит общеприменимые) и удивительные по настырности советы "пишите тесты!".
Потому что написание тестов, особенно до написания кода, помогает лучше понять как система должна работать.
M>Кстати, "динамические языки" — не такая большая ниша, так что пусть решают свои проблемы сами, без рекламы TDD.
Чем тебе TDD не угодил?
G>>Не приуменьшай важность тестирования как такового. А также разберись что такое TDD. M>Никто тесты не отрицает, но выпячивать их как панацею — встречается буквально в каждой первой статье о TDD.
Ну так не читай такой булшит, тебя же никто не заставляет.
M>Что забавно, Джоэл (в своих 12 признаках) даже словом не обмолвился о TDD. Есть повод задуматься.
А куча народу пишет только о TDD и ниче.
M>Лучший тестер по прежнему остаётся человек.
С чего бы?
Человек ошибается, а компьютер — нет.
unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, AndrewVK, Вы писали:
AVK>>И получится тест, который может выдавать разный результат в зависимости от фазы Луны.
FR>Угу а статистическая физика — лженаука
Статистической физика называется не потому что её законы выведены из статистических исследований, а потому что статистическое поведение системы почти всегда совпадает с результатами теоретических исследований.
Здравствуйте, gandjustas, Вы писали:
G>Статистической физика называется не потому что её законы выведены из статистических исследований, а потому что статистическое поведение системы почти всегда совпадает с результатами теоретических исследований.
M>>Лучший тестер по прежнему остаётся человек. G>С чего бы? G>Человек ошибается, а компьютер — нет. G>unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека.
Это в том случае, когда юнит-тесты и тесты интеграции представлены в виде проверяемых компьютером контрактов.
Читай — выражены в виде типов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
M>>>Лучший тестер по прежнему остаётся человек. G>>С чего бы? G>>Человек ошибается, а компьютер — нет. G>>unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека.
T>Это в том случае, когда юнит-тесты и тесты интеграции представлены в виде проверяемых компьютером контрактов.
Я про это чуть выше написал.
С задачей проверки контрактов компьютер тоже справляется лучше.
T>Читай — выражены в виде типов.
Это не единственный способ выражения контрактов.
M>>>>Лучший тестер по прежнему остаётся человек. G>>>С чего бы? G>>>Человек ошибается, а компьютер — нет. G>>>unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека. T>>Это в том случае, когда юнит-тесты и тесты интеграции представлены в виде проверяемых компьютером контрактов. G>Я про это чуть выше написал. G>С задачей проверки контрактов компьютер тоже справляется лучше.
Именно с ней он и справляется лучше всего.
T>>Читай — выражены в виде типов. G>Это не единственный способ выражения контрактов.
Ну, вырази контракт "не должно быть deadlock".
А теперь напиши тест, который это проверяет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Читай — выражены в виде типов. G>>Это не единственный способ выражения контрактов.
T>Ну, вырази контракт "не должно быть deadlock". T>А теперь напиши тест, который это проверяет.
А типами как такое сделать?
T>>>>Читай — выражены в виде типов. G>>>Это не единственный способ выражения контрактов. T>>Ну, вырази контракт "не должно быть deadlock". T>>А теперь напиши тест, который это проверяет. G>А типами как такое сделать?
Итак, ты не представляешь себе, как это выразить в контракте и как это проверить.
Здравствуйте, thesz, Вы писали:
T>>>>>Читай — выражены в виде типов. G>>>>Это не единственный способ выражения контрактов. T>>>Ну, вырази контракт "не должно быть deadlock". T>>>А теперь напиши тест, который это проверяет. G>>А типами как такое сделать?
T>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить.
В существующих языках — нет.
T>Вот, как это можно выразить в типах: http://edwinb.wordpress.com/2008/04/03/correct-by-construction-concurrency/
Создать другой язык — не совсем то что хотелось бы видеть.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
G>>>А типами как такое сделать? T>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>В существующих языках — нет.
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, thesz, Вы писали:
G>>>>А типами как такое сделать? T>>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>>В существующих языках — нет.
T>Придумай язык, вырази на нём.
Это портебует гораздо больше знаний и трудозатрат, чем обычное разруливание дедлоков.
T>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации.
Я в курсе про тяжесть ситуации.
T>>>Вот, как это можно выразить в типах: http://edwinb.wordpress.com/2008/04/03/correct-by-construction-concurrency/ G>>Создать другой язык — не совсем то что хотелось бы видеть. T>Если текущие языки неадекватны, зачем себя мучить?
Затем что создавать новые языки — нетривиальная задача.
Как там на лукоморье:
...необходимостью глубокого понимания лямбда-исчисления, замыканий, теории графов, теории категорий, сопромата, анатомии мозга и прочего матана даже для вывода на экран строки «Hello, World!»
G>>>>>А типами как такое сделать? T>>>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>>>В существующих языках — нет. T>>Придумай язык, вырази на нём. G>Это портебует гораздо больше знаний и трудозатрат, чем обычное разруливание дедлоков.
Да-да. Как когда-то распределение регистров.
Это же единовременное вложение, nes pa?
T>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>Я в курсе про тяжесть ситуации.
Нет, ты не в курсе.
G>>>Создать другой язык — не совсем то что хотелось бы видеть. T>>Если текущие языки неадекватны, зачем себя мучить? G>Затем что создавать новые языки — нетривиальная задача. G>Как там на лукоморье: G>
G>...необходимостью глубокого понимания лямбда-исчисления, замыканий, теории графов, теории категорий, сопромата, анатомии мозга и прочего матана даже для вывода на экран строки «Hello, World!»
Зато это сделает тебя лучшим, чем сейчас, программистом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, matumba, Вы писали:
M>Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!" (читай: ну вы и _удаки!) Да, возвышать себя унижая других — это древнее умение. M>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
Фактически, мои претензии к цементу состоят в его примитивности и РАЗДУТОЙ ШУМИХЕ вокруг него. Ни один _ля "профессионал" (коими кишат строительные форумы) никогда не делает оговорок об узкой применимости цемента — все только и умеют тыкать окружающих носом: "Как, вы кладете стены в многоэтажке, не используя цемент?!"
Кроме того, НИКТО не задает вопросов про стеклопакеты, кровельное железо, битум, паркет... Ухватились за то, на что мозгов хватило и давай пальцы груть!
Здравствуйте, thesz, Вы писали:
G>>>>>>А типами как такое сделать? T>>>>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>>>>В существующих языках — нет. T>>>Придумай язык, вырази на нём. G>>Это портебует гораздо больше знаний и трудозатрат, чем обычное разруливание дедлоков.
T>Это же единовременное вложение, nes pa?
Вряд ли, создание DSL под каждую задачу единовременным не будет.
Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.
T>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>Я в курсе про тяжесть ситуации. T>Нет, ты не в курсе.
Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи.
G>>>>Создать другой язык — не совсем то что хотелось бы видеть. T>>>Если текущие языки неадекватны, зачем себя мучить? G>>Затем что создавать новые языки — нетривиальная задача. G>>Как там на лукоморье: G>>
G>>...необходимостью глубокого понимания лямбда-исчисления, замыканий, теории графов, теории категорий, сопромата, анатомии мозга и прочего матана даже для вывода на экран строки «Hello, World!»
T>Зато это сделает тебя лучшим, чем сейчас, программистом.
Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится.
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
Я знаю одно замечательное свойство TDD: оно является средством, которое помогает программисту преодолеть лень и заставить самого себя сделать именно то, что нужно.;)
Разумеется, это не случай, когда над каждым стоит надсмотрщик — там и так запинают. Но я в таких местах не работаю, а работаю там, где больше свободы. А тут уже надо уметь себя заставить не отклоняться от задачи. И тогда — как только заметил, что начинается приступ лени — рисуешь тесты и получаешь самому себе причину не почитать RSDN или общаться с соседним отделом о перспективах версии 4.0 (когда ещё 1.0 не вышла), и тем более не цветного Штирлица смотреть, а кодить.
Ну и начальству яснее, когда говоришь, какое именно тестирование уже работает.
(Disclaimer: я имею в виду не только unit testing, но весь комплекс, включая функциональные и нагрузочные)
Здравствуйте, matumba, Вы писали:
M>Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!" (читай: ну вы и _удаки!) Да, возвышать себя унижая других — это древнее умение.
Тут можно понять обе стороны — и Вашу и противоположную. Да, тестирование само по себе примитивно;) Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? А оно даёт при выполнении соответствия кода тестам то, что:
1. То, что должно быть сделано (для соответствия тестам) — то сделано.
2. То, что не требуется (для соответствия тестам) — не делается.
ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка. Большая, жирная точка. Исполнитель сделал то, что должно быть сделано, и не делал (не тратил ресурсы) на то, что не должно делаться и на что не надо тратить ресурсы.
А дальше — два вопроса:
1. Кто начальник и как он наблюдает происходящее. Если, как в моём предыдущем сообщении в эту тему, я сам себе в значительной мере менеджер, по крайней мере по текущим задачам, я сам себе буду писать тесты. Если я, например, ленивый тормоз, не знающий ничего кроме какой-нибудь Явы, и то один год после заборостроительного техникума — надо мной будет стоять дядя с палкой, но оценивать он будет, скорее всего, по результатам тестов.
2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию — их может делать совсем другой человек с совсем другими знаниями (я уж не говорю про вариант, когда достаточно сказать make blackbox и в случае провала написать письмо — это и скрипт сумеет). И здесь неважно, программа это или автомат управления паровым котлом: тесты, хоть и разные, подойдут везде, вся технологическая промышленность всех видов строится на тестах.
M>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
T>>Это же единовременное вложение, nes pa? G>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.
Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency.
Это создание единовременно.
После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.
T>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>Я в курсе про тяжесть ситуации. T>>Нет, ты не в курсе. G>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи.
Какие?
T>>Зато это сделает тебя лучшим, чем сейчас, программистом. G>Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится.
Разница в производительности в два и более раз должна порадовать начальство.
Ты находишься в стандартной ловушке среднего программиста.
Во-первых, тебе требуется разрешение начальства. Уверяю, большинство полезных нововведений делается помимо этого разрешения. Хотя бы потому, что прощение получить проще, чем разрешение.
Во-вторых, тебе требуется разрешение начальства. Это означает, что твой рабочий день загружен до упора. У тебя нет пространства для маневра. Ты не можешь ничего ни написать, ни поэкспериментировать.
Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Это же единовременное вложение, nes pa? G>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.
T>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>Это создание единовременно.
Но очень затратно.
T>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.
Только читаемость в таком случае падает до 0.
T>>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>>Я в курсе про тяжесть ситуации. T>>>Нет, ты не в курсе. G>>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи. T>Какие?
Связанные с concurrency.
T>>>Зато это сделает тебя лучшим, чем сейчас, программистом. G>>Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится.
T>Разница в производительности в два и более раз должна порадовать начальство.
А затраты на достижение этого могут не порадовать.
T>Ты находишься в стандартной ловушке среднего программиста. T>Во-первых, тебе требуется разрешение начальства. Уверяю, большинство полезных нововведений делается помимо этого разрешения. Хотя бы потому, что прощение получить проще, чем разрешение. T>Во-вторых, тебе требуется разрешение начальства. Это означает, что твой рабочий день загружен до упора. У тебя нет пространства для маневра. Ты не можешь ничего ни написать, ни поэкспериментировать.
Есть планы, которые надо выполнять, желательно в срок.
T>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих.
Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>>>Это же единовременное вложение, nes pa? G>>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты. T>>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>>Это создание единовременно. G>Но очень затратно.
В том смысле, что придётся стать умнее? Да, затратно.
Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
T>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса. G>Только читаемость в таком случае падает до 0.
Это ты с чего взял?
Неужто из опыта? 8O
T>>>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>>>Я в курсе про тяжесть ситуации. T>>>>Нет, ты не в курсе. G>>>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи. T>>Какие? G>Связанные с concurrency.
То есть, ты умеешь тестировать на дедлоки. Или нет?
T>>>>Зато это сделает тебя лучшим, чем сейчас, программистом. G>>>Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится. T>>Разница в производительности в два и более раз должна порадовать начальство. G>А затраты на достижение этого могут не порадовать.
Вопрос баланса.
Даже если тебя снять со всех работ и дать тебе год на всё про всё, то за следующий год ты всё отобъёшь.
T>>Ты находишься в стандартной ловушке среднего программиста. T>>Во-первых, тебе требуется разрешение начальства. Уверяю, большинство полезных нововведений делается помимо этого разрешения. Хотя бы потому, что прощение получить проще, чем разрешение. T>>Во-вторых, тебе требуется разрешение начальства. Это означает, что твой рабочий день загружен до упора. У тебя нет пространства для маневра. Ты не можешь ничего ни написать, ни поэкспериментировать. G>Есть планы, которые надо выполнять, желательно в срок.
Они есть у всех.
T>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих. G>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL.
С доказанным 100% отсутствием — невозможно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, thesz, Вы писали:
T>>>>>Это же единовременное вложение, nes pa? G>>>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты. T>>>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>>>Это создание единовременно. G>>Но очень затратно.
T>В том смысле, что придётся стать умнее? Да, затратно.
Нет, в том смысле что создание такого dsl дороже, чем разруливание нескольких дедлоков.
T>Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
Это стоит перенести в раздел "О жизни".
Реквестирую статью о том как зависимая система типов помогает понимать больше шуток
T>>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса. G>>Только читаемость в таком случае падает до 0.
T>Это ты с чего взял? T>Неужто из опыта? 8O
Именно из опыта общения с различными с DSL.
T>>>>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>>>>Я в курсе про тяжесть ситуации. T>>>>>Нет, ты не в курсе. G>>>>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи. T>>>Какие? G>>Связанные с concurrency. T>То есть, ты умеешь тестировать на дедлоки. Или нет?
Нет, я умею их находить.
T>>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих. G>>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL.
T>С доказанным 100% отсутствием — невозможно.
А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества.
Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
Здравствуйте, thesz, Вы писали:
T>Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
Здравствуйте, gandjustas, Вы писали:
G>А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества. G>Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
Поддержу. Приемлимый уровень качества, за приемлимое время.
Автоматизированное (заметте не unit) тестирование это прекрасный способ достижения приемлимого компромисса.
А если бы все так простоы было с DSL, то у нас бы дааавным давно мейнстрим компиляторы детектировали дедлоки,
так же легко как и несоответсвие типов.
Но вот Ericson посчитали для себя обе перечеслинных проблемы неактуальными.
-- Главное про деструктор копирования не забыть --
T>>>>>>Это же единовременное вложение, nes pa? G>>>>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>>>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты. T>>>>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>>>>Это создание единовременно. G>>>Но очень затратно. T>>В том смысле, что придётся стать умнее? Да, затратно. G>Нет, в том смысле что создание такого dsl дороже, чем разруливание нескольких дедлоков.
Да его вариант на Хаскеле делается за, не знаю, два дня.
Тоже мне, "дороже".
T>>>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса. G>>>Только читаемость в таком случае падает до 0. T>>Это ты с чего взял? T>>Неужто из опыта? 8O G>Именно из опыта общения с различными с DSL.
DSL или DSEL?
G>>>Связанные с concurrency. T>>То есть, ты умеешь тестировать на дедлоки. Или нет? G>Нет, я умею их находить.
А как ты их находишь?
T>>>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих. G>>>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL. T>>С доказанным 100% отсутствием — невозможно. G>А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества. G>Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
"Простыми" в каком смысле?
Если в смысле "я уже умею так делать", это да. Проще.
Если в смысле "затраченных усилий" на единицу кода на длительном промежутке времени, то нет, не проще.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
FR>"Горе от ума"
Заметь, не от повышения уровня интеллекта (что можно измерить), а от ума.
FR>"Многие знания многие печали"
Соломон?
Я же не про Библию (да ещё и Старый Завет) говорил. В ней, действительно, совсем ничего радостного нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Это же единовременное вложение, nes pa? G>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.
T>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>Это создание единовременно.
T>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.
"и одним легким движеньем брюки..." (с)классика
можете привести пример (пример!) где используются 2 dsl и фраза "потом соединяешь их" не превращается в создание 3го dsl с выбрасыванием первых 2х.
Здравствуйте, kmmbvnr, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
G>>А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества. G>>Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
K>Поддержу. Приемлимый уровень качества, за приемлимое время.
K>Автоматизированное (заметте не unit) тестирование это прекрасный способ достижения приемлимого компромисса.
K>А если бы все так простоы было с DSL, то у нас бы дааавным давно мейнстрим компиляторы детектировали дедлоки, K>так же легко как и несоответсвие типов.
У них есть возможность бросать на проект большое количество программистов. Например, над AXD301 (или как он там) в конце проекта работало больше 100 человек (чуть ли не 150.
Для контор, где количество программистов на проект раз в двадцать меньше (5-7), этот метод не применим.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.
SD>"и одним легким движеньем брюки..." (с)классика SD>можете привести пример (пример!) где используются 2 dsl и фраза "потом соединяешь их" не превращается в создание 3го dsl с выбрасыванием первых 2х.
Если говорить о DSEL (язык, встроенный в язык), то таких примеров навалом.
Монады — один DSEL, разбор — другой, использующий абстракцию первого. Вешаем на разбор проверку типов — pBinExpr = do {x <- pexpr; op <- pbinop; y <- pExprAsType x; return $ op x y} — получается третий, строго типизированый разбор.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Да его вариант на Хаскеле делается за, не знаю, два дня. T>Тоже мне, "дороже".
Тут наверное все и так знают что у хаскеля пиписька длиннее.
Хотелось бы видеть пример на мйнстримовом языке.
T>>>>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса. G>>>>Только читаемость в таком случае падает до 0. T>>>Это ты с чего взял? T>>>Неужто из опыта? 8O G>>Именно из опыта общения с различными с DSL. T>DSL или DSEL?
Больше с обычными DSL и несколькими DSEL (на Ruby).
G>>>>Связанные с concurrency. T>>>То есть, ты умеешь тестировать на дедлоки. Или нет? G>>Нет, я умею их находить. T>А как ты их находишь?
Логи+дебаггер, как любые ошибки.
T>>>>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих. G>>>>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL. T>>>С доказанным 100% отсутствием — невозможно. G>>А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества. G>>Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
T>"Простыми" в каком смысле? T>Если в смысле "я уже умею так делать", это да. Проще.
В смысле "меньше думать и меньше писать".
T>Если в смысле "затраченных усилий" на единицу кода на длительном промежутке времени, то нет, не проще.
Тут стоит учитывать сумму по всем задачам, а то может выйти так что выигрываем в одном, а в другом проигрываем.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>Да его вариант на Хаскеле делается за, не знаю, два дня. T>>Тоже мне, "дороже". G>Тут наверное все и так знают что у хаскеля пиписька длиннее. G>Хотелось бы видеть пример на мйнстримовом языке.
Тебе шашечки, или ехать?
T>>DSL или DSEL? G>Больше с обычными DSL и несколькими DSEL (на Ruby).
Нашёл, кого в пример брать.
G>>>>>Связанные с concurrency. T>>>>То есть, ты умеешь тестировать на дедлоки. Или нет? G>>>Нет, я умею их находить. T>>А как ты их находишь? G>Логи+дебаггер, как любые ошибки.
А почему не можешь оттестировать?
T>>"Простыми" в каком смысле? T>>Если в смысле "я уже умею так делать", это да. Проще. G>В смысле "меньше думать и меньше писать".
"Меньше писать" это ты для красного словца, так?
T>>Если в смысле "затраченных усилий" на единицу кода на длительном промежутке времени, то нет, не проще. G>Тут стоит учитывать сумму по всем задачам, а то может выйти так что выигрываем в одном, а в другом проигрываем.
По моему опыту, объём и количество ошибок в самой рискованной части снижаются в разы, а объём кода в других частях растёт на проценты.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, thesz, Вы писали:
T>>>Да его вариант на Хаскеле делается за, не знаю, два дня. T>>>Тоже мне, "дороже". G>>Тут наверное все и так знают что у хаскеля пиписька длиннее. G>>Хотелось бы видеть пример на мйнстримовом языке.
T>Тебе шашечки, или ехать?
Дык мне именно "ехать".
Создание DSL пока что попадает в разряд шашечек.
G>>>>>>Связанные с concurrency. T>>>>>То есть, ты умеешь тестировать на дедлоки. Или нет? G>>>>Нет, я умею их находить. T>>>А как ты их находишь? G>>Логи+дебаггер, как любые ошибки. T>А почему не можешь оттестировать?
Потому что воссоздать окружение, гарарнтированное приводящее к дедлоку не всегда возможно, а даже когда возможно, то не всегда за приемлимое время
T>>>"Простыми" в каком смысле? T>>>Если в смысле "я уже умею так делать", это да. Проще. G>>В смысле "меньше думать и меньше писать". T>"Меньше писать" это ты для красного словца, так?
Нет
T>>>>Да его вариант на Хаскеле делается за, не знаю, два дня. T>>>>Тоже мне, "дороже". G>>>Тут наверное все и так знают что у хаскеля пиписька длиннее. G>>>Хотелось бы видеть пример на мйнстримовом языке. T>>Тебе шашечки, или ехать? G>Дык мне именно "ехать". G>Создание DSL пока что попадает в разряд шашечек.
В Одессе времен начала перестройки рассказывали такую историю. Некая дама выходит из здания аэровокзала. Носильщик везет за ней груду чемоданов и коробок. Дама восклицает: “Такси, такси!” Подъезжает легковушка, дама не обращает на нее внимания, продолжая покрикивать: “Такси, такси!” Легковушку перехватывает другой пассажир, к даме подъезжает еще одна машина, дама упускает и эту. Из третьей машины высовывается водитель: “Мадам, вам шашечки или ехать?”
В контексте данного обсуждения "ехать" — это использовать DSEL для 100%-го отсутствия ошибок. Я сомневаюсь, что мои слова можно толковать как-либо по-другому.
"Ехать с шашечками" — это использовать DSEL на мейнстримовом языке для 100%-го отсутствия ошибок.
Наличие шашечек для тебя важнее, чем сам процесс перемещения.
G>>>>>>>Связанные с concurrency. T>>>>>>То есть, ты умеешь тестировать на дедлоки. Или нет? G>>>>>Нет, я умею их находить. T>>>>А как ты их находишь? G>>>Логи+дебаггер, как любые ошибки. T>>А почему не можешь оттестировать? G>Потому что воссоздать окружение, гарарнтированное приводящее к дедлоку не всегда возможно, а даже когда возможно, то не всегда за приемлимое время
Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным.
Киваешь на начальство, которое это одобряет.
T>>>>"Простыми" в каком смысле? T>>>>Если в смысле "я уже умею так делать", это да. Проще. G>>>В смысле "меньше думать и меньше писать". T>>"Меньше писать" это ты для красного словца, так? G>Нет
Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь?
Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, netch80, Вы писали:
N> Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? ...... N>ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка.
Ну так мы ж не про то, как отвязаться от начальства! Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!
N>2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию
Это смотря какой уровень качества вы хотите гарантировать. Допустим, вы даёте на вход А, должны получить Б. Тест проходит на ура, но что, если подали Х? Это усложнение теста и тестирующий просто обязан знать как система должна отреагировать на "мусор" и _проверить_ это. А если "неправильное Х" ещё и должно быть отослано по мылу? (Хотел бы я видеть такой тест!) У меня башка идёт кругом от тех вариаций, которые могут провалить тест! Воистину, только от немногих знаний можно так оптимистично смотреть на unit testing.
M>>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
N>Так ветка-то не про них.
Как это не про них??? Читаем исходное сообщение:
>В последнее время сталкиваюсь с большим колличеством советов обязательно использовать unit testing — проскакивает во многих подкастах .NET Rocks и Hanselminutes,...
Вот про этих "подкастоболов" и речь. Человек даже гуглом не стал ограничиваться — написал на форум, узнать как РЕАЛЬНО обстоят дела. На мой параноидальный взгляд, проходит "организованная шумиха" вокруг технологии, заслуживающей максимум упоминания на лекции. "Fire and motion" в действии, фигли...
Здравствуйте, thesz, Вы писали: T>Ну, вырази контракт "не должно быть deadlock".
Есть формальные критерии дедлока T>А теперь напиши тест, который это проверяет. А вот с этим — облом. Можно сделать либо язык/среду, в которой дедлоки в принципе невозможны (дийкстра, гармонически взаимодействующие процессы. Сиомега, рандеву.), и тогда всё доказуемо статически. Либо дедлок возможен, и вместо теста будет контр-тест.
Ну, точнее можно придумать решение на основе системы, допускающей дедлоки в принципе, и проверить, что это решение успешно избегает дедлоков в оговорённых сценариях. Но это всего лишь тестирование оговорённых сценариев, не более того.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, matumba, Вы писали: M>Ну так мы ж не про то, как отвязаться от начальства! Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!
Просто unit testing — наименее интрузивная форма внедрения автоматизации тестирования вообще.
На моём термометре показан крайне низкий уровень QA-культуры в стране вообще. Грубо говоря, рядовые куашники, ушедшие из нашей компании по результатам аттестации, успешно становились в других компаниях начальниками QA-отделов. И это при том, что я абсолютно недоволен состоянием нашего QA.
TDD — это вообще за пределами практического применения для подавляющего большинства российских коллективов. Поэтому обсуждать его результаты — примерно то же самое, что во времена Жюль Верна спорить о полезностях обратной стороны Луны. Нам бы сначала DDT (development-driven testing) внедрить, чтобы проверить состояние уже написанного кода. А уж потом можно попробовать понять, реально ли писать автоматические тесты на основе спецификаций (а не на основе обсуждений с девелоперами и наблюдаемого поведения).
Вот несколько лет назад на RSDN пробегал прикольный пример DDT — где автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression: как только менялось хоть что-то, SVN видел change. При этом совершенно не требовалось мучительно изобретать тесты по спецификации, а потом сводить их с реализацией (которая запросто может отличаться от ожиданий. Неужто никто не правил SRS по результатам неудачных попыток реализовать его?).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>На моём термометре показан крайне низкий уровень QA-культуры в стране вообще.
Этак и до правительства добраться можно! Но этот низкий уровень — всего лишь индикатор как жлобство влияет на качество. Но мы-то сами должны разбираться в вопросе! Если мне дадут мильён и скажут "выбирай любую методику и реализуй", TDD — последнее, на что я потрачусь.
S>TDD — это вообще за пределами практического применения для подавляющего большинства российских коллективов.
Думаю, после слова "применения" уже можно было поставить точку. Слишком много "но" у этой методы, чтобы успешно влезать в конвейер разработки.
S>...автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression
Я так понимаю, речь идёт об оценке производительности и не упала ли она? Regression — какой-то неудачный термин, degradation test был бы уместнее. Но это на отлаженном коде! И требующем всё же некой мат.обработки. А нам бы вообще добиться верного результата.
Здравствуйте, Sinclair, Вы писали:
S>TDD — это вообще за пределами практического применения для подавляющего большинства российских коллективов. Поэтому обсуждать его результаты — примерно то же самое, что во времена Жюль Верна спорить о полезностях обратной стороны Луны. Нам бы сначала DDT (development-driven testing) внедрить, чтобы проверить состояние уже написанного кода.
А что такое development-driven testing? Просто тесты к уже написанному коду?
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, netch80, Вы писали:
N>> Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? ...... N>>ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка.
M>Ну так мы ж не про то, как отвязаться от начальства! Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!
Ты очередно раз говоришь чушь, не надоело?
С чего ты взял что unit testing вообще хоть как-то применим к сложным системам?
Ты упорно не понимаешь сути того, что пытаешься ругать.
N>>2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию
M>Это смотря какой уровень качества вы хотите гарантировать. Допустим, вы даёте на вход А, должны получить Б. Тест проходит на ура, но что, если подали Х? Это усложнение теста и тестирующий просто обязан знать как система должна отреагировать на "мусор" и _проверить_ это. А если "неправильное Х" ещё и должно быть отослано по мылу? (Хотел бы я видеть такой тест!) У меня башка идёт кругом от тех вариаций, которые могут провалить тест!
А декомпозировать задачу не пробовал? Или у тебя в программе есть один класс на 10000 строк, который делает все?
M>Воистину, только от немногих знаний можно так оптимистично смотреть на unit testing. От немногих знаний можно так рассуждать о unit testing.
Здравствуйте, thesz, Вы писали:
T>В контексте данного обсуждения "ехать" — это использовать DSEL для 100%-го отсутствия ошибок. Я сомневаюсь, что мои слова можно толковать как-либо по-другому. T>"Ехать с шашечками" — это использовать DSEL на мейнстримовом языке для 100%-го отсутствия ошибок.
На самом деле "ехать" — создавать код с приемлимым уровнем качества, а вот "100% отсуствие, доказанное из системы типов" — шашечки.
Пока что такое мало где возможно и требует очень много от программиста.
T>Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным.
Логи только при отладке, в релизе отключаются.
T>>>>>"Простыми" в каком смысле? T>>>>>Если в смысле "я уже умею так делать", это да. Проще. G>>>>В смысле "меньше думать и меньше писать". T>>>"Меньше писать" это ты для красного словца, так? G>>Нет
T>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь?
При фиксированном времени раздумий — да.
T>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню.
Что такое CbCC?
Здравствуйте, matumba, Вы писали:
S>>...автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression M>Я так понимаю, речь идёт об оценке производительности и не упала ли она? Regression — какой-то неудачный термин, degradation test был бы уместнее.
Зато стандартный. Относится, кстати, и к случаю, когда перестало проходить тест.
Здравствуйте, matumba, Вы писали:
N>> Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? ...... N>>ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка.
M>Ну так мы ж не про то, как отвязаться от начальства!
Я вообще-то про случай, когда надо не "отвязаться", а сделать работу.:) При этом критерии по весьма полезной счастливой случайности совпадают с типичными критериями _хорошего_ начальства (которое думает о деле, а не о том, как затрахать подчинённого или посадить своего племянника на тёплое местечко).
M> Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!
Никто не перегрелся. Просто находит, как себе же облегчить работу. Простая практическая статистика: если тестирования не делаешь совсем, гоняешь сразу готовую систему — находится огромное количество случаев, которые могли быть отловлены юнит-тестированием. А затраты на локализацию и опознание ошибки в разы больше, чем на юнит-тестирование. Встаёт простой вопрос — а зачем такое позволять? Чем сложнее система, тем важнее всё, что ловится на уровне отдельного модуля, ловить таки на уровне отдельного модуля. С какого-то порога таки нужен TDD, чтобы форсировать разработку тестов до написания кода. Насколько строго он будет соблюдаться во временнОм плане — уже не так важно, jIMHO (это я про то, что нет причины всегда писать тесты до кода, но сданной работой считается только такая, к которой нарисованы и пройдены тесты в нужном объёме).
N>>2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию M>Это смотря какой уровень качества вы хотите гарантировать. Допустим, вы даёте на вход А, должны получить Б. Тест проходит на ура, но что, если подали Х? Это усложнение теста и тестирующий просто обязан знать как система должна отреагировать на "мусор" и _проверить_ это.
А что значит "как должна отреагировать"? Для большинства случаев, меня устроит, если она на недопустимые значения вывалит исключение, а что именно в этом исключении — уже неважно.
И что тут сложного в проверке? Пишешь функцию типа
M> А если "неправильное Х" ещё и должно быть отослано по мылу? (Хотел бы я видеть такой тест!) У меня башка идёт кругом от тех вариаций, которые могут провалить тест! Воистину, только от немногих знаний можно так оптимистично смотреть на unit testing.
Погоди, ты смешиваешь совершенно разные вещи, и явно от недостатка знаний. Для случаев "отослано по мылу" не надо проверять прохождение письма через почту. Достаточно поставить адекватную заглушку (mock) вместо функции отправки по мылу, а затем просто установить флаг по факту вызова этой функции с нужными данными.
Юнит-тестирование с заглушками — совершенно нормальный вариант, и я не знаю, чем он тебя так пугает. Сложностью настройки обстановки, чтобы он работал? Да, это сложнее, чем просто запустить функцию.
M>>>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
N>>Так ветка-то не про них.:)
M>Как это не про них??? Читаем исходное сообщение:
>>В последнее время сталкиваюсь с большим колличеством советов обязательно использовать unit testing — проскакивает во многих подкастах .NET Rocks и Hanselminutes,...
M>Вот про этих "подкастоболов" и речь. Человек даже гуглом не стал ограничиваться — написал на форум, узнать как РЕАЛЬНО обстоят дела. На мой параноидальный взгляд, проходит "организованная шумиха" вокруг технологии, заслуживающей максимум упоминания на лекции. "Fire and motion" в действии, фигли...
Ты так говоришь, будто за это кто-то бабло будет лопатой грести.:) нет, всё проще. Чем больше индусов из заборостроительного техникума и китайцев из Гуанжопы ((c) некто cathay-stray), тем больше необходимость учить самому базовому.
А системное тестирование всё равно никуда не денется, точно также как нагрузочное и прочее.
Здравствуйте, matumba, Вы писали:
M> "морда к базе" с транзакциями — и то уже проблема!
Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.
Тестировал отдельно PL/SQL процедуры, самописными ассертами — нет проблем.
Тестировал сайты, сразу все кучей бд и контролеры — нет проблем.
Недавно в форуме проскакивала ссылка на статью Фаулера о Руби, он там сравнивал
опыт двух подходов к тестированию и не пришел к однозначному выводу что лучше.
-- Главное про деструктор копирования не забыть --
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>В контексте данного обсуждения "ехать" — это использовать DSEL для 100%-го отсутствия ошибок. Я сомневаюсь, что мои слова можно толковать как-либо по-другому. T>>"Ехать с шашечками" — это использовать DSEL на мейнстримовом языке для 100%-го отсутствия ошибок. G>На самом деле "ехать" — создавать код с приемлимым уровнем качества, а вот "100% отсуствие, доказанное из системы типов" — шашечки. G>Пока что такое мало где возможно и требует очень много от программиста.
Я сейчас, несмотря на свой "уровень" (считающийся высоким и мной в том числе), поражаюсь тому, как много может программист, вооружённый Хаскелем.
T>>Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным. G>Логи только при отладке, в релизе отключаются.
И что, неужто дедлоков у заказчиков не было? Ни за что не поверю.
T>>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь? G>При фиксированном времени раздумий — да.
Иными словами, ты признаешь, что тебя работа задалбывает настолько, что даже нет времени подумать.
T>>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню. G>Что такое CbCC?
Correct by Construction Concurrency.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным. G>>Логи только при отладке, в релизе отключаются. T>И что, неужто дедлоков у заказчиков не было? Ни за что не поверю.
Конечно было. Даже было такое что локально воспроизвести ситуацию не удавалось.
Ну отправили заказчикам дебажный бинарь, а потом по логам достаточно быстро нашли причину.
T>>>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь? G>>При фиксированном времени раздумий — да. T>Иными словами, ты признаешь, что тебя работа задалбывает настолько, что даже нет времени подумать.
Не вижу связи.
T>>>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню. G>>Что такое CbCC? T>Correct by Construction Concurrency.
Я примерно на 5 странице перестал понимать что там написано.
Здравствуйте, kmmbvnr, Вы писали:
M>> "морда к базе" с транзакциями — и то уже проблема!
K>Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.
Видите — уже привлекается IoC, про которое опять ни слова от продвигателей TDD (а существующую систему без IoC вообще никто переписывать не будет). Но суть остаётся та же: юнит тестинг делать желательно, если на это есть ресурсы, покрытие тестов вас удовлетворяет и что объект теста настолько нестабилен, что имеет смысл держать его в узде.
K>Недавно в форуме проскакивала ссылка на статью Фаулера о Руби, он там сравнивал K>опыт двух подходов к тестированию и не пришел к однозначному выводу что лучше.
А вы не могли бы найти по каким-то ключевым словам, плиз? Боюсь, что я по "фаулер" и "руби" вряд ли найду что-то однозначное.
Здравствуйте, Sinclair, Вы писали:
S>Вот несколько лет назад на RSDN пробегал прикольный пример DDT — где автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression: как только менялось хоть что-то, SVN видел change. При этом совершенно не требовалось мучительно изобретать тесты по спецификации, а потом сводить их с реализацией (которая запросто может отличаться от ожиданий. Неужто никто не правил SRS по результатам неудачных попыток реализовать его?).
Это я был
Тесты для немерле примерно также устроены.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, matumba, Вы писали:
M>Я так понимаю, речь идёт об оценке производительности и не упала ли она? Regression — какой-то неудачный термин, degradation test был бы уместнее.
Нет. Производительность тут ни каким боком.
А регрессия это когда что-то где-то поменял и что-то другое сломалось.
Это и ловится.
M>Но это на отлаженном коде!
Ну да. Чтобы получить эталонный лог нужно отладить код.
M>И требующем всё же некой мат.обработки.
Чё?
M>А нам бы вообще добиться верного результата.
А что с этим есть проблемы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Я же не про Библию (да ещё и Старый Завет) говорил. В ней, действительно, совсем ничего радостного нет.
FR>Так современные психологи и социологи тоже говорят Счастье — прибежище идиотов
Есть другое мнение: между IQ и удовольствием от жизни связь настолько прямая, что людей с очень высоким IQ среди так называемых "успешных" найти очень сложно. Они настолько довольны жизнью, что им многое пофиг, всё, что им надо, они могут добиться своими силами по необходимости.
Это совпадает с китайским определением истинного мудреца, для которого только время преграда.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>>>Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным. G>>>Логи только при отладке, в релизе отключаются. T>>И что, неужто дедлоков у заказчиков не было? Ни за что не поверю. G>Конечно было. Даже было такое что локально воспроизвести ситуацию не удавалось. G>Ну отправили заказчикам дебажный бинарь, а потом по логам достаточно быстро нашли причину.
И это считается нормальным.
T>>>>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь? G>>>При фиксированном времени раздумий — да. T>>Иными словами, ты признаешь, что тебя работа задалбывает настолько, что даже нет времени подумать. G>Не вижу связи.
Ну, и ладно.
T>>>>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню. G>>>Что такое CbCC? T>>Correct by Construction Concurrency. G>Я примерно на 5 странице перестал понимать что там написано.
Во-от.
Я на Software People специально ходил на доклады товарищей из Agile, в частности и про TDD.
Уровень образования чудовищно низок.
Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
Здравствуйте, thesz, Вы писали:
G>>Конечно было. Даже было такое что локально воспроизвести ситуацию не удавалось. G>>Ну отправили заказчикам дебажный бинарь, а потом по логам достаточно быстро нашли причину. T>И это считается нормальным.
Да потому что альтернативы автоматизированному тестированию это:
1) Абсолютно глюсчный бинарь, который "и не раз еще вернется", и не важно от кого от заказчика либо
от локальных тестеров.
2) Самому до посинения кликать мышкой и клацать по клавиатуре.
3) Освоить тулзы с суровой типизацией aka cтать таким же суровым как thesz.
Да третий вариант очень интересный, можно подчерпнуть множество полезных техник и подходов,
применимых не только с использованием Haskell, но есть несколько минусов.
Как минимум есть множество задач, связанных с взаимодействием с множеством сторонних библиотек и платформ. В этих
случаях мне кажется гораздо быстрее использовать автоматизированное тестирование, нежли надеятся на авось.
T>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив.
Я вот не помню того момента как я учил паскаль. Точно знаю что до универа я знал только С и Basic, а в универе я
уже первую программу на паскале писал за деньги однокурсникам. С PL/SQL я тоже как-то пришел и сразу в продакшен стал
лить код. И опять же деньги.
У type driven очень не нулевой порог входа.
Тут с людьми приходится работать которым система контроля версий дается с трудом, не говоря уже о CbCC,
Haskell и сопутствующих технологиях.
T>Э-эх.
Компросисс.
Оффтопик: T>Уровень образования чудовищно низок. T>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
О спасибо. Составляю тут набор вопросов для отбора стажеров. Хочется чтобы люди с пользой провели время в гугле,
и пока отвечают, приобщались к прекрасному. Что такое REPL — ооотличный вопрос.
-- Главное про деструктор копирования не забыть --
Здравствуйте, thesz, Вы писали:
T>Есть другое мнение: между IQ и удовольствием от жизни связь настолько прямая, что людей с очень высоким IQ среди так называемых "успешных" найти очень сложно. Они настолько довольны жизнью, что им многое пофиг, всё, что им надо, они могут добиться своими силами по необходимости.
Ну между мнением и исследованиями есть небольшая такая разница
Если серъезно есть корреляция между степенью аутотеличности и степенью счастья, а IQ тут ни причем.
Слово «аутотелический» состоит из двух греческих корней: «ауто» (сам, самостоятельный) и «телос» (цель). Аутотелическая деятельность – это деятельность, которой мы занимаемся ради нее самой, поскольку нашей основной целью является опыт данной деятельности. Например, если бы я играл в шахматы, только для того чтобы получить удовольствие от игры, то игра была бы для меня аутотелическим опытом. В то время как, если бы я играл на деньги или чтобы завоевать высокое место в шахматном мире, то та же самая игра была бы экзотелическим опытом, то есть мотивированным внешними целями. Что касается аутотелической личности, то она означает человека, который в основном занимается чем-то ради самого этого занятия, а не для того чтобы достичь какой-то внешней цели.
Здравствуйте, thesz, Вы писали:
T>Я на Software People специально ходил на доклады товарищей из Agile, в частности и про TDD. T>Уровень образования чудовищно низок.
Как связаны уровень образования и TDD?
T>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац.
Люди пишущие на <название языка> не знают что такое <какой-нить акроним>. Можно написать генератор таких фраз, примено 90% из них будут верны.
T>Смотрим на твои сообщения: "ты просто не понимаешь TDD
". T>Выясняется, что пропонент TDD, которое Test Driven Design, не может понять TDD, которое Type Driven Design.
С чего ты взял?
T>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив. T>Да и не желаешь, поскольку начальство довольно не будет
. T>Э-эх.
Да ладно, будь с собой честен. Сколько языков поддерживает Type Driven Design в таком виде? Видимо только Haskell.
А есть у Haskell фреймворк уровня ASP.NET? Есть ли готовые платформы вроде SharePoint? Можно ли программу на Haskell запускать в браузере, как Silverlight?
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, kmmbvnr, Вы писали:
M>>> "морда к базе" с транзакциями — и то уже проблема!
K>>Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.
M>Видите — уже привлекается IoC, про которое опять ни слова от продвигателей TDD (а существующую систему без IoC вообще никто переписывать не будет). Но суть остаётся та же: юнит тестинг делать желательно, если на это есть ресурсы, покрытие тестов вас удовлетворяет и что объект теста настолько нестабилен, что имеет смысл держать его в узде.
Я не согласен с вашей фразой, отдельно по частям и вообще полностью.
M>уже привлекается IoC
Если я привлеку ASP.NET для написания вебсайтов, что теперь Ritch Internet Application есть вселенское зло?
IoC архитектура привлекается в основном не ради тестирования. Удобство для автоматизированного тестирования получаем for free.
Тестировать можно и без IoC, и без тестовых фреймворков, и вообще руками все нажимать. Но зачем?
M> TDD ... существующую систему
Употребление TDD рядом с "Существующей системой", просто некорректно. Чувствуется традиционное заблуждение что unit-тесты эквивалентно TDD.
M> если на это есть ресурсы Лично у меня
с автоматическими тестами производительность больше чем без тестов. Мне не понятно почему это тесты требуют больших ресурсов.
M> покрытие тестов вас удовлетворяет
Любое покрытие тестами является более удовлетворительным чем их полное отсутствие.
M> объект теста настолько нестабилен
Если у мне не понятно как делать 10% проекта, и я хожу кругами переделывая это по несколько раз, это не повод не тестировать остальные 90%
M>А вы не могли бы найти по каким-то ключевым словам, плиз? Боюсь, что я по "фаулер" и "руби" вряд ли найду что-то однозначное.
matumba,
K>>Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.
M>Видите — уже привлекается IoC, про которое опять ни слова от продвигателей TDD (а существующую систему без IoC вообще никто переписывать не будет).
Есть неинтрузивные ioc-контейнеры, например Autofac для .net. И наличие ioc ортогонально наличию юнит-тестов вообще. ioc + mocks просто удобнее в плане реализации юниттестов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>Я на Software People специально ходил на доклады товарищей из Agile, в частности и про TDD. T>>Уровень образования чудовищно низок. G>Как связаны уровень образования и TDD?
Type Driven Design? Напрямую.
T>>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац. G>Люди пишущие на <название языка> не знают что такое <какой-нить акроним>. Можно написать генератор таких фраз, примено 90% из них будут верны.
Ты уж извини, но REPL для динамических языков дело святое.
T>>Смотрим на твои сообщения: "ты просто не понимаешь TDD
T>>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив. T>>Да и не желаешь, поскольку начальство довольно не будет
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Есть другое мнение: между IQ и удовольствием от жизни связь настолько прямая, что людей с очень высоким IQ среди так называемых "успешных" найти очень сложно. Они настолько довольны жизнью, что им многое пофиг, всё, что им надо, они могут добиться своими силами по необходимости.
FR>Ну между мнением и исследованиями есть небольшая такая разница
FR>Если серъезно есть корреляция между степенью аутотеличности и степенью счастья, а IQ тут ни причем.
The other point I found interesting was when Gladwell alluded to the fact that most brilliant children don't become "successful" but usually have "happy" lives. He suggests that it is an almost deliberate choice, i.e. because they were brilliant they realized the combination of sacrifices and luck needed to become successful, and determined it just wasn't worth it.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Читай — выражены в виде типов. G>>Это не единственный способ выражения контрактов.
T>Ну, вырази контракт "не должно быть deadlock".
Можно попросить провести маленький ликбез в порядке просвящения? Вот есть хорошая задача: даны два банковских счета и нужно провести операцию перевода денег с одного на другой. На псевдокоде это выражается приблизительно так:
Данный код приводит к тупикам. Как можно описать контракт для типов Account и/или операции transfer, чтобы гарантировать, что операция не будет вести к тупикам?
Если можно на пальцах с применением C/Java- или Pascal-, или Python-онобразного псевдокода. А то у меня от коротких примеров на Haskell крышу сносит.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
K>Как минимум есть множество задач, связанных с взаимодействием с множеством сторонних библиотек и платформ. В этих K>случаях мне кажется гораздо быстрее использовать автоматизированное тестирование, нежли надеятся на авось.
Я не против.
Но с альтернативой надо быть знакомым.
T>>Получается, что ты пользуешься TDD не из-за того, что сознательно выбрал, а из-за того, что не понимаешь альтернатив. K>Я вот не помню того момента как я учил паскаль. Точно знаю что до универа я знал только С и Basic, а в универе я K>уже первую программу на паскале писал за деньги однокурсникам. С PL/SQL я тоже как-то пришел и сразу в продакшен стал K>лить код. И опять же деньги. K>У type driven очень не нулевой порог входа.
Сейчас попробую сформулировать получше различия.
Test Driven Design/Development использует тесты, чтобы контролировать правильность внесения изменений после изменений спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является примерное местоположение неправильно работающей части программы. Программа с ошибкой в тестировании может быть запущена и отдана заказчику. Ответ на вопрос "почему так" оставлен на программиста. Вероятность обнаружения ошибки связана с качеством написания тестов, которая зависит от автора теста — рядового члена команды. Это связано с большим объёмом работы по написанию тестов.
Type Driven Design/Development использует типы, чтобы контролировать правильность внесения изменения после изменения спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является местоположение неправильно работающей части программы. Программа с ошибкой в типах не может быть запущена и отдана заказчику. Ответ на вопрос "почему так" может быть получен из диагностики системы. Вероятность обнаружения ошибки связана с качеством системы типов и точностью задания спецификации типов уровнем выше, что может быть выполнено людьми более опытными, чем рядовой член команды, поскольку объём работы меньше.
Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты).
Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
T>>>>Читай — выражены в виде типов. G>>>Это не единственный способ выражения контрактов.
T>>Ну, вырази контракт "не должно быть deadlock".
E>Можно попросить провести маленький ликбез в порядке просвящения? Вот есть хорошая задача: даны два банковских счета и нужно провести операцию перевода денег с одного на другой. На псевдокоде это выражается приблизительно так: E>
Вот пример блокировки оттуда:
1. Simon sends Phil £20, beginning by executing lock(Simon).
2. Phil sends John £10, beginning by executing lock(Phil).
3. John sends Simon £42, beginning by executing lock(John).
4. Now all three resources are locked—none of the processes can lock the resource associated with the receiver! The system is deadlocked.
E>Как можно описать контракт для типов Account и/или операции transfer, чтобы гарантировать, что операция не будет вести к тупикам?
Упорядочить блокируемые ресурсы.
Simon<Phil<John
E>Если можно на пальцах с применением C/Java- или Pascal-, или Python-онобразного псевдокода. А то у меня от коротких примеров на Haskell крышу сносит.
1. Simon sends Phil £20, beginning by executing lock(Simon).
2. Phil sends John £10, beginning by executing lock(Phil).
3. John sends Simon £42, beginning by executing lock(Simon) (Simon<John).
Теперь Фил пошлёт Джону денежку и разлочится, Семён пошлёт Филу денежку и разлочится и (ура!) Джон пошлёт Саймону денежку.
Основная задача состоит в том, чтобы на уровне типов заставить Account иметь операцию сравнения и заставить lock выполняться сперва над меньшим операндом. И чтобы операция сравнения была представима в виде DAG.
Если мы присобачим к lock операнд lockContext, то мы можем сделать что-то вроде такого:
lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) { обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
-- этого нет в Java, но:
,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
-- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
-- и в ничто (давая ошибку типа) в противном случае
) {
блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
}
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
The other point I found interesting was when Gladwell alluded to the fact that most brilliant children don't become "successful" but usually have "happy" lives. He suggests that it is an almost deliberate choice, i.e. because they were brilliant they realized the combination of sacrifices and luck needed to become successful, and determined it just wasn't worth it.
T>)
Угу полно блестящих талантливых людей с не очень высоким IQ
.
Т.е. мок инфраструктуры детектирует дедлок (бросая, к примеру, ексепшн вместо зависания), а мок-аккаунты занимаются тем, что искусственно продляют время транзакции для 100% гарантии наступления дедлока, если он возможен.
Тест тогда запускает две одновременных транзакции transfer(a, b, 100) | transfer (b, a, 100). Приведённый тобой код получит дедлок, после чего у программиста появится повод переписать его вот так:
transfer(from: Account; to: Account; amount: Money) {
var first = Min(from, to);
var second = Max(from, to);
lock(first) {
lock(second) {
a.debit(ammount)
b.credit(ammount)
}
}
}
После этого, очевидно, дедлок возникать перестанет. Заодно тест сможет проверить, что все инварианты корректно выполнены — в частности, вот такой код
transfer(from: Account; to: Account; amount: Money)
{
a.debit(ammount)
b.credit(ammount)
}
дедлока вызывать не будет, но сумма (from.Balance + to.Balance) изменится после отработки теста.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, thesz, Вы писали:
T>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.
Еще не стоит забывать что эти методы не является полностью взаимозаменяемыми.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.
FR>Еще не стоит забывать что эти методы не является полностью взаимозаменяемыми.
Да. Тесты при этом уменьшаются до функциональных, приблизительно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Основная задача состоит в том, чтобы на уровне типов заставить Account иметь операцию сравнения и заставить lock выполняться сперва над меньшим операндом. И чтобы операция сравнения была представима в виде DAG.
T>Если мы присобачим к lock операнд lockContext, то мы можем сделать что-то вроде такого: T>
T>lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) {
T> -- обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
T>lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
T> -- этого нет в Java, но:
T> ,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
T> -- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
T> -- и в ничто (давая ошибку типа) в противном случае
T> ) {
T> блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
T>}
T>
Может я чего-то недопонимаю, но все это держится на представлении о том, что программист, реализующий операцию transfer, должен внутри вызвать правильную последовательность функций lock. А потребовать от него это мы можем лишь заставив операцию transfer иметь прототип вида:
LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
transfer(from: Account, to: Account, ammount: Money) ...
Без этого требования программист вполне может по ошибке или недосмотру использовать в реализации transfer функцию lock первого вида. Т.е. надо было бы сделать так:
Здравствуйте, eao197, Вы писали:
E>Может я чего-то недопонимаю, но все это держится на представлении о том, что программист, реализующий операцию transfer, должен внутри вызвать правильную последовательность функций lock. А потребовать от него это мы можем лишь заставив операцию transfer иметь прототип вида: E>
E>LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
E>transfer(from: Account, to: Account, ammount: Money) ...
E>
И, в догонку... Об ошибках. Даже такой прототип не защитит от глупой ошибки вида:
LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
transfer(from: Account, to: Account, ammount: Money) {
l = lock(from, lock(from, Empty))
from.debit(ammount)
to.credit(ammount)
return l;
}
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Может я чего-то недопонимаю, но все это держится на представлении о том, что программист, реализующий операцию transfer, должен внутри вызвать правильную последовательность функций lock. А потребовать от него это мы можем лишь заставив операцию transfer иметь прототип вида: E>
E>LockContext<Pair<Account_Index,Pair<Account_Index,Empty>>
E>transfer(from: Account, to: Account, ammount: Money) ...
E>
По-моему, всё понимаешь.
E>Без этого требования программист вполне может по ошибке или недосмотру использовать в реализации transfer функцию lock первого вида. Т.е. надо было бы сделать так: E>
Поэтому товарищи внесли LockContext в монаду, в которой происходит lock. Контекст передаётся неявно.
E>Но все это идет лесом, если transfer должен будет возвращать, к примеру, состояния счетов from и to на момент завершения операции.
Этого я не понял, прошу прощения.
Если у нас есть пары, то мы можем вернуть и пару состояний счетов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>По-моему, всё понимаешь.
Блин, после этого утверждения я немерянно вырос в собственных глазах!
E>>Но все это идет лесом, если transfer должен будет возвращать, к примеру, состояния счетов from и to на момент завершения операции.
T>Этого я не понял, прошу прощения.
T>Если у нас есть пары, то мы можем вернуть и пару состояний счетов.
Я о том, что программу может интересовать только transfer вида:
Pair<AccountState,AccountState> transfer(from, to, amount) {...}
информация о блокировках внутри transfer -- это детали реализации, которые, по-хорошему, не должны быть видны снаружи transfer-а.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
T>Test Driven Design/Development использует тесты, чтобы контролировать правильность внесения изменений после изменений спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является примерное местоположение неправильно работающей части программы. Программа с ошибкой в тестировании может быть запущена и отдана заказчику. Ответ на вопрос "почему так" оставлен на программиста. Вероятность обнаружения ошибки связана с качеством написания тестов, которая зависит от автора теста — рядового члена команды. Это связано с большим объёмом работы по написанию тестов.
Это очень поеврхностный взгляд на тестирование.
1)ни одна версия не уходит в релиз, пока не пройдены все тесты
2)вероятность пропуска бага зависит от непокрытого тестами участка кода
3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
4)есть инструменты автоматической генерации тестов (pex), которые позволяют автоматизировать whitebox тестирование
T>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты).
В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.
T>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится.
Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.
T>>Test Driven Design/Development использует тесты, чтобы контролировать правильность внесения изменений после изменений спецификаций. Результатом обнаружения ошибки, если она была обнаружена, является примерное местоположение неправильно работающей части программы. Программа с ошибкой в тестировании может быть запущена и отдана заказчику. Ответ на вопрос "почему так" оставлен на программиста. Вероятность обнаружения ошибки связана с качеством написания тестов, которая зависит от автора теста — рядового члена команды. Это связано с большим объёмом работы по написанию тестов. G>Это очень поеврхностный взгляд на тестирование.
Ты просто не дал себе труда обдумать.
G>1)ни одна версия не уходит в релиз, пока не пройдены все тесты
Но может? Может. У меня так и написано.
G>2)вероятность пропуска бага зависит от непокрытого тестами участка кода
И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка.
G>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода
Также относится и к другому методу, поэтому перпендикулярно дискуссии.
G>4)есть инструменты автоматической генерации тестов (pex), которые позволяют автоматизировать whitebox тестирование
И вывод типов с Квикчеком, ага.
Кстати, pex применим только к строго типизированным языкам. Попробуй натравить его на Smalltalk, хотя бы гипотетически.
Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
T>>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты). G>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам.
В этом плане TyDD выгоднее, поскольку на тебя работают умнейшие люди планеты. Они, как бы, незримо присутствуют в команде.
T>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится. G>Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.
Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править.
TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design.
Так что, иди, разбирайся, что же такое TDD.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>1)ни одна версия не уходит в релиз, пока не пройдены все тесты T>Но может? Может. У меня так и написано.
Это зависит от того как построен процесс разработки. По-хорошему — не может. Кроме автоматизированного тестирования есть еще тестирования людями, а они получают только билд со всеми автоматическими успешными тестами.
Некоторые системы сборки, как TFS, позволяют запретить коммиты в репозитарий при нарушенном билде.
G>>2)вероятность пропуска бага зависит от непокрытого тестами участка кода T>И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка.
Самое смешное что все будет ОК, если нету сценариев, когда в эту функцию передается 0
А вообще можно pex натравить на такой метод, быстро все найдет.
G>>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода T>Также относится и к другому методу, поэтому перпендикулярно дискуссии.
У меня есть сомнения что системой типов можно адекватно выразить что делает код, в случае более-менее большого куска.
Например я писал интеграционный тест для автоматической регистрации:
сначала вызывается метод регистрации (на него непосредственно приходит управление),
потом вызывается метод с нужными параметрами, полученными "из текста письма" (на самом деле там фейк, который письма никуда не отправляет),
потом метод логина в систему с теми же именем пользователя и пароля что и при регистрации.
Соотвественно проверялось что логин в таком случае будет успешен.
Как такое системой типов выразить?
T>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD.
Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?
T>>>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты). G>>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам. T>В этом плане TyDD выгоднее, поскольку на тебя работают умнейшие люди планеты. Они, как бы, незримо присутствуют в команде.
Умнейших людей планеты на всех не хватит, а софт кому-то писать надо.
T>>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится. G>>Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.
T>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править. T>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design.
ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества?
T>Так что, иди, разбирайся, что же такое TDD.
Не по адресу.
Здравствуйте, gandjustas, Вы писали:
T>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD. G>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?
Ну, вообще говоря, без статической типизации Pex работать бы не смог. Я так понял, что Pex — это попытка получить все что возможно от доказывателя теорем в условиях системы типов, для которой все статически доказать нельзя, но автоматически сгенерировать тесты можно.
Да и к TDD он имеет весьма опосредованное отношение — если писать тесты раньше чем код — много ли от Pex-а будет толку?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
T>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD. G>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?
K>Ну, вообще говоря, без статической типизации Pex работать бы не смог. Я так понял, что Pex — это попытка получить все что возможно от доказывателя теорем в условиях системы типов, для которой все статически доказать нельзя, но автоматически сгенерировать тесты можно.
Вообще говоря почти все автоматизированное тестирования от недостатка статических проверок.
K>Да и к TDD он имеет весьма опосредованное отношение — если писать тесты раньше чем код — много ли от Pex-а будет толку?
Дофига. Так как можно писать тесты для success сценариев, а pex может обнаружить все fail сценарии.
Мне показалось или вы противопоставляете тестирование и типизацию?
Здравствуйте, thesz, Вы писали:
T>>>>>Читай — выражены в виде типов. G>>>>Это не единственный способ выражения контрактов.
T>>>Ну, вырази контракт "не должно быть deadlock".
E>>Можно попросить провести маленький ликбез в порядке просвящения? Вот есть хорошая задача: даны два банковских счета и нужно провести операцию перевода денег с одного на другой. На псевдокоде это выражается приблизительно так:
... E>>Данный код приводит к тупикам.
T>http://www.cs.st-andrews.ac.uk/~eb/drafts/icfp08.pdf
T>Вот пример блокировки оттуда:
... E>>Как можно описать контракт для типов Account и/или операции transfer, чтобы гарантировать, что операция не будет вести к тупикам?
T>Упорядочить блокируемые ресурсы.
... T>Основная задача состоит в том, чтобы на уровне типов заставить Account иметь операцию сравнения и заставить lock выполняться сперва над меньшим операндом. И чтобы операция сравнения была представима в виде DAG.
T>Если мы присобачим к lock операнд lockContext, то мы можем сделать что-то вроде такого: T>
T>lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) { обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
T>lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
T> -- этого нет в Java, но:
T> ,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
T> -- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
T> -- и в ничто (давая ошибку типа) в противном случае
T> ) {
T> блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
T>}
T>
мне вот стало интересно как там у умнейших людей планеты обстоят дела с раздельной компиляцией
T>>lock(lockContext : LockContext<Empty>, account : Account<Account_Index>) { обычная блокировка, вернём LockContext<Pair<Account_Index,Empty>> }
T>>lock(lockContext : LockContext<Pair<PrevAcc,Tail>>, account : Acccount<ThisAcc>
T>> -- этого нет в Java, но:
T>> ,dummy : TypeLevel_Less(PrevAcc,ThisAcc) := unit -- чтобы не указывать аргументом
T>> -- TypeLevel_Less переписывает пару типов в unit, если первый меньше второго
T>> -- и в ничто (давая ошибку типа) в противном случае
T>> ) {
T>> блокировка, вернём LockContext<Pair<ThisAcc,Pair<Account_Index,Empty>>>
T>>}
T>>
SD>мне вот стало интересно как там у умнейших людей планеты обстоят дела с раздельной компиляцией
Отлично!
Ты бы вместо ёрничанья задавал бы конкретные вопросы. Было бы лучше.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
G>>>1)ни одна версия не уходит в релиз, пока не пройдены все тесты T>>Но может? Может. У меня так и написано. G>Это зависит от того как построен процесс разработки. По-хорошему — не может. Кроме автоматизированного тестирования есть еще тестирования людями, а они получают только билд со всеми автоматическими успешными тестами. G>Некоторые системы сборки, как TFS, позволяют запретить коммиты в репозитарий при нарушенном билде.
Иными словами, дело процесса.
Ты, видимо, воспринимаешь процесс, как нечто железное, которое нельзя преодолеть.
G>>>2)вероятность пропуска бага зависит от непокрытого тестами участка кода T>>И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка. G>Самое смешное что все будет ОК, если нету сценариев, когда в эту функцию передается 0 G>А вообще можно pex натравить на такой метод, быстро все найдет.
Примени pex к тексту на Перле.
G>>>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода T>>Также относится и к другому методу, поэтому перпендикулярно дискуссии. G>У меня есть сомнения что системой типов можно адекватно выразить что делает код, в случае более-менее большого куска. G>Например я писал интеграционный тест для автоматической регистрации: G>сначала вызывается метод регистрации (на него непосредственно приходит управление), G>потом вызывается метод с нужными параметрами, полученными "из текста письма" (на самом деле там фейк, который письма никуда не отправляет), G>потом метод логина в систему с теми же именем пользователя и пароля что и при регистрации. G>Соотвественно проверялось что логин в таком случае будет успешен. G>Как такое системой типов выразить?
Видишь ли, если я начну тебе объяснять, то ты меня "перестанешь понимать уже на пятой странице".
Тем не менее: http://blog.sigfpe.com/2009/02/beyond-monads.html
У нас есть такая волшебная "точка с запятой" под названием >>=, она же bind. Она соединяет "вычисление из контекста A в контекст B" с "вычислением из контекста B в контекст C".
Например, мы можем перейти из контекста "ничего не сделано" в контекст "получили параметры". Затем мы можем перейти в контекст "произвели логин". И тп.
Нет ничего магического.
Кстати, в Sing# примерно так и сделано. Только, как всегда, криво и косо.
T>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD. G>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо?
Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться.
T>>>>Итак, основная разница в том, кто ответственен за вероятность пропущенной в окончательное приложение ошибки. В случае TeDD это все члены команды, в случае TyDD это старшие (более опытные) члены команды и авторы системы типов (очень умные люди, в случае языков типа Хаскель/Coq/Agda2 — умнейшие люди планеты). G>>>В этом плане TeDD выгоднее, так как позволяет более быстро обучаться менее опытным разработчикам. T>>В этом плане TyDD выгоднее, поскольку на тебя работают умнейшие люди планеты. Они, как бы, незримо присутствуют в команде. G>Умнейших людей планеты на всех не хватит, а софт кому-то писать надо.
Ну что ты за глупости говоришь.
Ты и так уже пользуешься результатами работы Microsoft. Тот же pex работает у тебя и у твоего коллеги. Так и типы от умнейших людей планеты будут работать и у меня, и у моего коллеги, и у тебя, если ты дашь себе труд немного почитать.
T>>>>Другая разница состоит в необходимости править программу до упора, пока не заработает в случае TyDD. Кому-то это нравится, кому-то нет. Мне нравится. G>>>Аналогично в TeDD — надо править пока не проходятся все тесты. Иначе смысла в тестировании нету.
T>>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править. T>>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design. G>ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества?
Да.
Это часть процесса, который можно отменить и/или подправить в текущий момент.
T>>Так что, иди, разбирайся, что же такое TDD. G>Не по адресу.
У тебя ещё и чувства юмора нет. Ох.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>Это же единовременное вложение, nes pa? DM>>n'est-ce pas L>Мне кажется, thesz копировал Выбегалло. Но я тоже обратил внимание, что он написал латиницей. L>Это показательный пример того, почему на рсдн флеймов больше, чем топиков
thesz взял это выражение из одного из текстов Yello (конкретно, Bostich), где в своё время было nes pa (а сейчас уже того варианта не найти).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, thesz, Вы писали:
G>>>>1)ни одна версия не уходит в релиз, пока не пройдены все тесты T>>>Но может? Может. У меня так и написано. G>>Это зависит от того как построен процесс разработки. По-хорошему — не может. Кроме автоматизированного тестирования есть еще тестирования людями, а они получают только билд со всеми автоматическими успешными тестами. G>>Некоторые системы сборки, как TFS, позволяют запретить коммиты в репозитарий при нарушенном билде.
T>Иными словами, дело процесса. T>Ты, видимо, воспринимаешь процесс, как нечто железное, которое нельзя преодолеть.
Это уже зависит от того, кто процессом управляет... Но это уже тема для другого раздела форума.
G>>>>2)вероятность пропуска бага зависит от непокрытого тестами участка кода T>>>И от квалификации пишущего тесты. Он может создать тест, который заходит в процедуру с делением на входное значение и не подать туда 0. Покрытие есть, есть и ошибка. G>>Самое смешное что все будет ОК, если нету сценариев, когда в эту функцию передается 0 G>>А вообще можно pex натравить на такой метод, быстро все найдет.
T>Примени pex к тексту на Перле.
Pex работает на уровне IL, а не на исходниках. Когда perl научится в .NET компилироваться, тогда посмотрим
Хотя и там вряд ли получится.
G>>>>3)использование тестов перед кодом позволяет один раз задумываться что код должен делать, это почти всегда приводит к сокращению написанного кода T>>>Также относится и к другому методу, поэтому перпендикулярно дискуссии. G>>У меня есть сомнения что системой типов можно адекватно выразить что делает код, в случае более-менее большого куска. G>>Например я писал интеграционный тест для автоматической регистрации: G>>сначала вызывается метод регистрации (на него непосредственно приходит управление), G>>потом вызывается метод с нужными параметрами, полученными "из текста письма" (на самом деле там фейк, который письма никуда не отправляет), G>>потом метод логина в систему с теми же именем пользователя и пароля что и при регистрации. G>>Соотвественно проверялось что логин в таком случае будет успешен. G>>Как такое системой типов выразить?
T>Видишь ли, если я начну тебе объяснять, то ты меня "перестанешь понимать уже на пятой странице".
Мне для этого понадобилась пара десятков строк.
T>Тем не менее: http://blog.sigfpe.com/2009/02/beyond-monads.html T>У нас есть такая волшебная "точка с запятой" под названием >>=, она же bind. Она соединяет "вычисление из контекста A в контекст B" с "вычислением из контекста B в контекст C". T>Например, мы можем перейти из контекста "ничего не сделано" в контекст "получили параметры". Затем мы можем перейти в контекст "произвели логин". И тп. T>Нет ничего магического.
Ну то что подобное можно написать на хаскеле я не сомневаюсь (было бы странно иначе), но как обеспечить статическую проверку сценария?
Стоит учеть, что каджый метод в отдельности имеет кучу сценариев работы.
T>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD. G>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо? T>Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться.
Ну в .NET и java есть статические типы, но именно в них TeDD находит такое широкое применнение.
T>>>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править. T>>>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design. G>>ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества? T>Да. T>Это часть процесса, который можно отменить и/или подправить в текущий момент.
Слабоватый агрумент. На сильную типизацию при желании тоже забить можно, в тестах ассерты закомменитить итп.
T>>Иными словами, дело процесса. T>>Ты, видимо, воспринимаешь процесс, как нечто железное, которое нельзя преодолеть. G>Это уже зависит от того, кто процессом управляет... Но это уже тема для другого раздела форума.
Возможность не зависит от того, кто управляет процессом.
T>>Тем не менее: http://blog.sigfpe.com/2009/02/beyond-monads.html T>>У нас есть такая волшебная "точка с запятой" под названием >>=, она же bind. Она соединяет "вычисление из контекста A в контекст B" с "вычислением из контекста B в контекст C". T>>Например, мы можем перейти из контекста "ничего не сделано" в контекст "получили параметры". Затем мы можем перейти в контекст "произвели логин". И тп. T>>Нет ничего магического. G>Ну то что подобное можно написать на хаскеле я не сомневаюсь (было бы странно иначе), но как обеспечить статическую проверку сценария? G>Стоит учеть, что каджый метод в отдельности имеет кучу сценариев работы.
Да, бляха муха, возьми и напиши. Чего ты меня мучаешь в стиле "как написать? вот, как ты написал, я это и так понимаю, а как написать?"
В детстве у нас похожий сценарий назывался "купи слона".
"Я понимаю, что ты на Хаскеле это напишешь, но ты купи слона!"
T>>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD. G>>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо? T>>Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться. G>Ну в .NET и java есть статические типы, но именно в них TeDD находит такое широкое применнение.
Ты и с историей TeDD не знаком. Он же родом из Смолтока, Кент Бек (который экстремальное программирование) его автор.
В .Net и Java отвратительная статическая типизация, это я тебе ответственно заявляю и здесь многие поддержат это моё мнение. Неудивительно, что в них применяется метод из совсем уж слабых языков программирования.
T>>>>Если Development — TeDDv, — да, надо править. Если Design — TeDDn — нет, не надо править. T>>>>TyDD такая штука, что заставит тебя сделать и Development, хоть ты и начинал с Design. G>>>ты серьезно считаешь что можно релизить код, который не проходит процедуру контроля качества? T>>Да. T>>Это часть процесса, который можно отменить и/или подправить в текущий момент. G>Слабоватый агрумент. На сильную типизацию при желании тоже забить можно, в тестах ассерты закомменитить итп.
Ну, давай, забей на статическую типизацию.
Отключи её, бляха муха, в твоей программе на C#.
То, что делается специальными средствами, не допускающими коммита, не проходящего тесты, в языках со статической типизацией выполняется обычным make.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>>Поэтому аргумент насчёт pex мы отбросим, как неорганизованный — он относится только к части языков, где может быть TDD. G>>>>Не понял логики.. pex — генератор тестов, почему его отбрасывать надо? T>>>Он не работает в случае языков типа Smalltalk. Он работает только для языков, где есть статические типы, а там и TyDD можно пользоваться. G>>Ну в .NET и java есть статические типы, но именно в них TeDD находит такое широкое применнение.
T>Ты и с историей TeDD не знаком. Он же родом из Смолтока, Кент Бек (который экстремальное программирование) его автор.
Отлично знаком. И что что родом из смолтока? все ООП родом из смолтока, правда на смолток нифига не похоже...
T>В .Net и Java отвратительная статическая типизация, это я тебе ответственно заявляю и здесь многие поддержат это моё мнение.
Да и я поддержу.
T>Неудивительно, что в них применяется метод из совсем уж слабых языков программирования.
А вот тут не согласен. Тестирование и TDD вполне достойные методы сами по себе.
Ты все пытаешься доказать что при хорошей системе типов они не нужны, но как-то неубедительно.
(Если че — я не пытаюсь доказать обратное)
Здравствуйте, 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>>
Здравствуйте, thesz, Вы писали:
T>>>В .Net и Java отвратительная статическая типизация, это я тебе ответственно заявляю и здесь многие поддержат это моё мнение. G>>Да и я поддержу.
T>>>Неудивительно, что в них применяется метод из совсем уж слабых языков программирования. G>>А вот тут не согласен. Тестирование и TDD вполне достойные методы сами по себе. G>>Ты все пытаешься доказать что при хорошей системе типов они не нужны, но как-то неубедительно.
T>Нужно функциональное тестирование, а не интеграционное и ниже уровнями.
Если тестирование уровнями ниже вполне заменяется статическими проверками, то да. Но если написание типов гораздо сложнее (требует больше знаний и\или времени) чем написание тестов, то тесты могут оказаться выгоднее.
Здравствуйте, AndrewVK, Вы писали:
G>>А чего ты тогда хочешь доказать? AVK>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата.
Функциональные требования вполне формальны или формализуемы. Для реализации этих требований и подходит TDD.
Есть еще нефункционалтные треования, для которых возможно TDD не подойдет вообще, но их небольшая часть.
G>>>>Во-вторых при правльном применении AVK>>>Опять бла-бла-бла. Ты не мудри, ты пальцем покажи. G>>http://blog.wekeroad.com/mvc-storefront/kona-2/ AVK>Что я там должен увидеть?
Скринкаст.
G>>Если оптимизиация вызывает изменнеие дизайна, то надо переделать тесты. AVK>Курица или яйцо? Откуда взялись изначальные тесты?
При первоначальной реализации требований.
AVK>>>То есть ты с определением в википедии не согласен? Приведи другое определение из какого нибудь внешнего по отношению к тебе источника. G>>Я уже давно выяснил, написанное в википедии про TDD\BDD\DDD\IoC и прочие буквосочетания имеет мало общего с реальностью. Написано может быть и правильно, но не то что нужно. G>>Поэтому предпочитаю смотреть код и смотреть как люди пишут этот код.
AVK>
AVK>Приведи другое определение из какого нибудь внешнего по отношению к тебе источника.
AVK>Если не можешь, так и скажи.
Я вообще в определениях не силен, лучше ссылки накидаю на демонстрацию TDD.
G>>Какой конкретики? AVK>Ответов на конкретные вопросы. Я тебе их уже много в этом топике задавал.
Какие из них связаны с написанием\дизайном кода?
Отвечать на вопросы мироздания с помощью TDD не получится.
G>>Если хочешь — давай конкретные требования AVK>А если их нет, конкретных и формальных? Если у меня они есть, я и без тебя знаю, что да как. Наличие таких требований уже больше 50% решения задачи.
Для формализации требований применяются свои средства, не имеющие отношения к дизайну кода.
G>>А я не говорил что ты его не использовал AVK>Тогда к чему тирада про устриц? Ты кого имел в виду?
G>>, я лишь говорю что если мнение о TDD построено на википедии AVK>Нет, мое мнение не построено на википедии. Просто в википедии, на мой взгляд, вполне неплохое изложение идеи. И, уж извини, какой бы плохой википедия не была, я ей как то больше доверяю, чем твоим бездоказательным утверждениям, основанным на том, что ты где то что то непонятно что видел или читал. Да, на всякий случай — умные книжки про TDD читал, реальные проекты с его использованием видел, и даже сам применял. Так что больше не стоит про устриц или непонимание, ок?
Ну тогда не стоит ссылками из википедии кидаться, у меня скоро на них отторжение будет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>Предположим. Тогда на момент написания тестов TDD мы никакой конкретикой по прежнему не знаем, точной спецификации нет. Значит и тесты непонятно как писать. G>>И как в таких условиях вообще код писать или проектированием заниматься? AVK>А что, ты не смог бы? Обыкновенно — включаешь моск и вперед.
Я бы сначала уточнением требований занаялся. Хотя бы usecase (или как принятол называть у агилистов user stories) собрать, они достаточно формальны чтобы по ним можно было код писать.
G>>>>Я в прототипах не парюсь и пишу логику в button_click, никаким дизайном там и не пахнет. AVK>>>Я что то как то не уловил смысла этой фразы. Не мог бы ты поподробнее свою мысль изложить? G>>Мысль в том что прототим делается не для дизайна, а для того чтобы более наглядно представить требования или идею, которую хочется реализаовать.
AVK>Тогда возвращаемся к началу — если нет формальных требований, а есть лишь набор критериев и относительная важность каждого из них, как применять TDD? Формальные тесты уже, в немалой степени, определят дизайн решения на уровне контрактов юнитов. А у нас как раз и стоит задача разработки такого дизайна, а не чтобы тупо налопатить код в рамках готового дизайна.
Не понимаю как это. Вот есть набор критериев: чтобы быстро работало и чтобы было читаемо, ни слова о функциональности.
Что тут можно написать?
А если есть функциональность, тогда пишем тесты, делаем функционал, помня о читаемости подключаем тулзы проверки coding styles\design guidelines, после прохождения всех тестов показываем заказчику (или проводим нагрузочное тестирование), если быстродействие устраивает то сделали, если нет, тогда оптимизируем.
G>>Прототип помогает избавиться от неопределенности и противоречивости в требованиях. AVK>Каким образом, интересно? Можно на конкретном примере?
Об этом написано в книге «Программист-прагматик» Эндрю Ханта и Дэйва Томаса.
Здравствуйте, gandjustas, Вы писали:
G>Я бы сначала уточнением требований занаялся.
Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе.
G> Хотя бы usecase (или как принятол называть у агилистов user stories) собрать, они достаточно формальны чтобы по ним можно было код писать.
Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых.
G>Не понимаю как это. Вот есть набор критериев: чтобы быстро работало и чтобы было читаемо, ни слова о функциональности.
Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования. Ну и поом — что, на нефункциональные требования вообще забиваем? Или ты хочешь сказать, что они не влияют на дизайн? Или ты считаешь, что при TDD нужно реализовать функциональные требования, а потом начинать рефакторить дизайн и тесты в угоду требованиям нефункциональным?
G>А если есть функциональность, тогда пишем тесты, делаем функционал, помня о читаемости подключаем тулзы проверки coding styles\design guidelines, после прохождения всех тестов показываем заказчику (или проводим нагрузочное тестирование), если быстродействие устраивает то сделали, если нет, тогда оптимизируем.
А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD?
AVK>>Каким образом, интересно? Можно на конкретном примере? G>Об этом написано в книге
Гы
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
AVK>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата. G>Функциональные требования вполне формальны или формализуемы.
Любые? Это даже не смешно.
G>Есть еще нефункционалтные треования, для которых возможно TDD не подойдет вообще, но их небольшая часть.
Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек?
G>>>>>Во-вторых при правльном применении AVK>>>>Опять бла-бла-бла. Ты не мудри, ты пальцем покажи. G>>>http://blog.wekeroad.com/mvc-storefront/kona-2/ AVK>>Что я там должен увидеть? G>Скринкаст.
Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах.
AVK>>Курица или яйцо? Откуда взялись изначальные тесты? G>При первоначальной реализации требований.
А мы, если ты заметил, именно о первоначальной реализации и говорим.
G>Я вообще в определениях не силен, лучше ссылки накидаю на демонстрацию TDD.
Лучше — не надо. Потому что это не отвечает на мои вопросы. Я сам могу так красиво подобрать пример, чтобы TDD работал. Вопрос то не в том, что да как с TDD, где оно хорошо подходит, а в том, что да как, если подходит плохо.
Давай тебе еще один пример. Хочу я, к примеру (судя по твоим агитациям, ты с предметом хорошо знаком), сбацать свой IoC контейнер. У меня при этом есть ряд притензий к контейнерам существующим + желание сделать качественный дизайн. Не какой то конкретный, а качественный. Теперича я хочу этот дизайн таки воплотить в жизнь при помощи TDD. Именно дизайн, собственно реализация там смешная, ничего проблематичного, оно меня не интересует. Вот и раскажи мне последовательность действий.
AVK>>Ответов на конкретные вопросы. Я тебе их уже много в этом топике задавал. G>Какие из них связаны с написанием\дизайном кода?
С дизайном — все.
G>Отвечать на вопросы мироздания с помощью TDD не получится.
Я от тебя наоборот конкретики прошу, а ты мне как раз таки все больше про мироздание.
G>Для формализации требований применяются свои средства, не имеющие отношения к дизайну кода.
А требования к дизайну, их тоже делают средствами, не имеющими отношения к дизайну?
G>Ну тогда не стоит ссылками из википедии кидаться
Ну ты то ничего лучше не можешь сказать. Ок, давай тогда расскажи, что тебе в википедии не нравится. Конкретно.
G>, у меня скоро на них отторжение будет.
Ага, тяжело оно, когда конкретика
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
T>>Люди, пишущие на Perl, не знают, что такое REPL. Полный абзац. N>Знаешь, я тоже, как журденовский герой, не знал этого сокращения, пока не заглянул после твоего постинга в словарь (хотя использую ежедневно). Потому что у нас это называется "language interpreter shell" В то же время _расшифрованная_ аббревиатура была понятна с первой же секунды.
N>Если ты хотел этим REPL показать уровень, то пример выбран явно неудачно.
Везде это REPL.
Там language interpreter shell.
Нет слов.
15 слогов, конечно, не требуемые 17, но и так неплохо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Нужно функциональное тестирование, а не интеграционное и ниже уровнями.
G>Если тестирование уровнями ниже вполне заменяется статическими проверками, то да. Но если написание типов гораздо сложнее (требует больше знаний и\или времени) чем написание тестов, то тесты могут оказаться выгоднее.
Написание типов требует разительно меньше строк кода. Типы хранятся рядом с вычислениями, а не в отдельном файле (как обычно бывает с тестами). Типы не требуют специальной системы сборки.
Наличие большего количества знаний выгодно на длительном промежутке времени. Стратегически, так сказать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>thesz взял это выражение из одного из текстов Yello (конкретно, Bostich), где в своё время было nes pa (а сейчас уже того варианта не найти).
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Я бы сначала уточнением требований занаялся. AVK>Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе.
Ок, приведи пример.
G>> Хотя бы usecase (или как принятол называть у агилистов user stories) собрать, они достаточно формальны чтобы по ним можно было код писать. AVK>Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых.
Неверно слово написал, сами usecase неформальны, но функциональность системы вполне формализуема по ним.
G>>Не понимаю как это. Вот есть набор критериев: чтобы быстро работало и чтобы было читаемо, ни слова о функциональности.
AVK>Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования.
и что такой криетрий дает?
AVK>Ну и поом — что, на нефункциональные требования вообще забиваем? Или ты хочешь сказать, что они не влияют на дизайн? Или ты считаешь, что при TDD нужно реализовать функциональные требования, а потом начинать рефакторить дизайн и тесты в угоду требованиям нефункциональным?
Почти так. Нефункциональные требования должны учитываться при дизайне, но сами по себе они никак дизайн не определяют.
G>>А если есть функциональность, тогда пишем тесты, делаем функционал, помня о читаемости подключаем тулзы проверки coding styles\design guidelines, после прохождения всех тестов показываем заказчику (или проводим нагрузочное тестирование), если быстродействие устраивает то сделали, если нет, тогда оптимизируем.
AVK>А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD?
При TDD получается слабосвязный код, подменить один компонент другим (гораздо более быстродейственным) ничего не стоит.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата. G>>Функциональные требования вполне формальны или формализуемы. AVK>Любые? Это даже не смешно.
Это правда. Все зависит от желания того кто занимается анализом.
G>>Есть еще нефункционалтные треования, для которых возможно TDD не подойдет вообще, но их небольшая часть. AVK>Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек?
На проектах, моих и не только.
Есть факты, подтверждающие обратное — говори.
AVK>Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах.
Там не игрушечный пример.
AVK>>>Курица или яйцо? Откуда взялись изначальные тесты? G>>При первоначальной реализации требований. AVK>А мы, если ты заметил, именно о первоначальной реализации и говорим.
И как ты эту реализацию делать собираешься если у тебя нету ни одного функционального требования?
Вот сделай программу: интерфейс должен быть удобным, они должна работать быстро, код должен быть простой в поддержке.
G>>Я вообще в определениях не силен, лучше ссылки накидаю на демонстрацию TDD. AVK>Лучше — не надо. Потому что это не отвечает на мои вопросы. Я сам могу так красиво подобрать пример, чтобы TDD работал. Вопрос то не в том, что да как с TDD, где оно хорошо подходит, а в том, что да как, если подходит плохо.
Ну так приведи адекватный пример, где подходит плохо, а то единственное что ты пока придумал — полное отсуствие функциональных требований, но в таких условиях вообще ни одна программа не будет написана.
Пока что был один пример где TDD не работает — concurrency, но там вообще мало чего работает, особенно если рассматривать мэинстримовые языки.
AVK>Давай тебе еще один пример. Хочу я, к примеру (судя по твоим агитациям, ты с предметом хорошо знаком), сбацать свой IoC контейнер. У меня при этом есть ряд притензий к контейнерам существующим + желание сделать качественный дизайн. Не какой то конкретный, а качественный. Теперича я хочу этот дизайн таки воплотить в жизнь при помощи TDD. Именно дизайн, собственно реализация там смешная, ничего проблематичного, оно меня не интересует. Вот и раскажи мне последовательность действий.
Ну рассказывай, какой функционал ты хочешь от этого контейнера?
AVK>>>Ответов на конкретные вопросы. Я тебе их уже много в этом топике задавал. G>>Какие из них связаны с написанием\дизайном кода? AVK>С дизайном — все.
покачто ни одного.
G>>Ну тогда не стоит ссылками из википедии кидаться AVK>Ну ты то ничего лучше не можешь сказать. Ок, давай тогда расскажи, что тебе в википедии не нравится. Конкретно.
Еще раз, в википедии написано может быть правильно, но совсем не то что нужно.
То что нужно — лучше показывать, чем описывать словами.
Здравствуйте, gandjustas, Вы писали:
AVK>>Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе. G>Ок, приведи пример.
Я уже приводил два примера.
AVK>>Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых. G>Неверно слово написал, сами usecase неформальны, но функциональность системы вполне формализуема по ним.
Вот в этом я сильно не уверен. Например, не получив прототип дизайна, нельзя с абсолютной уверенностью выбрать золотую середину между противоречивыми требованиями. Как следствие — до появления дизайна первой итерации противоречие это разрешить не получится.
AVK>>Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования. G>и что такой криетрий дает?
Направление эволюции дизайна.
G>Почти так. Нефункциональные требования должны учитываться при дизайне, но сами по себе они никак дизайн не определяют.
То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно.
AVK>>А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD? G>При TDD получается слабосвязный код, подменить один компонент другим (гораздо более быстродейственным) ничего не стоит.
Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
AVK>>>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата. G>>>Функциональные требования вполне формальны или формализуемы. AVK>>Любые? Это даже не смешно. G>Это правда.
Это не правда. Продолжим?
AVK>>Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек? G>На проектах, моих и не только. G>Есть факты, подтверждающие обратное — говори.
О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь
AVK>>Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах. G>Там не игрушечный пример.
Он игрушечный в том плане, что заранее подходит для TDD.
AVK>>А мы, если ты заметил, именно о первоначальной реализации и говорим. G>И как ты эту реализацию делать собираешься если у тебя нету ни одного функционального требования?
А кто сказал что ни одного?
G>Ну так приведи адекватный пример
Я уже приводил. Если примеры тебе не нравяться, я не виноват. Удобного для тебя примера, я, очевидно, не приведу, в том то и суть.
G>, где подходит плохо, а то единственное что ты пока придумал — полное отсуствие функциональных требований, но в таких условиях вообще ни одна программа не будет написана.
Я тебе привел два конкретных примера. Про полное отсутствие функциональных требований ты придумал сам.
G>Ну рассказывай, какой функционал ты хочешь от этого контейнера?
Упрощение разработки определенного типа приложений.
G>>>Ну тогда не стоит ссылками из википедии кидаться AVK>>Ну ты то ничего лучше не можешь сказать. Ок, давай тогда расскажи, что тебе в википедии не нравится. Конкретно. G>Еще раз, в википедии написано может быть правильно, но совсем не то что нужно.
Так, еще раз — в википедии написано конкретное определение. Это именно то, что нужно. Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе.
G>То что нужно — лучше показывать, чем описывать словами.
Ясно. Я тебе так скажу — если ты даже базовые вещи не можешь сформулировать, ни о каком твоем понимании TDD говорить не приходится. И обвинения твои в том, что не понимает TDD кто то там, они выглядят, сам понимаешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>Ты не понял — уточнять не у кого, прото потому что более точных требований не существует в природе. G>>Ок, приведи пример. AVK>Я уже приводил два примера.
Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится, так что не подходит.
А второй — что?
AVK>>>Да ну брось ты, они как раз таки как правило неформальны. А может и вообще не быть, потому что источник изменения внутри. Или может быть много, противоречивых. G>>Неверно слово написал, сами usecase неформальны, но функциональность системы вполне формализуема по ним. AVK>Вот в этом я сильно не уверен. Например, не получив прототип дизайна, нельзя с абсолютной уверенностью выбрать золотую середину между противоречивыми требованиями. Как следствие — до появления дизайна первой итерации противоречие это разрешить не получится.
Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями.
AVK>>>Почему ни слова. К функциональности тоже критерии — например, некая функциональность должна стать удобнее. Или для некоторой подсистемы Х должен улучшиться код ее использования. G>>и что такой криетрий дает? AVK>Направление эволюции дизайна.
"некая функциональность должна стать удобнее" какое направление эволюции дизайна дает?
G>>Почти так. Нефункциональные требования должны учитываться при дизайне, но сами по себе они никак дизайн не определяют. AVK>То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно.
Вообще не опеределяют, так как величины эмпирические. Невозможно задать целевое значение этой характеристики и его добиваться при разработке.
Кроме того понятия читаемости и легкости модификации сильно субъективны и зависят от того, кто будет чтением и модификацией заниматься.
AVK>>>А если в текущем дизайне быстродействие улучшить не удается и надо серьезно этот дизайн менять? Выкидываем тесты и забиваем на TDD? G>>При TDD получается слабосвязный код, подменить один компонент другим (гораздо более быстродейственным) ничего не стоит. AVK>Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую.
А с чего ты взял что впустую?
1)тесты написанные перед кодом фиксируют требования к этому коду, поэтому не надо держать требования в голове, что сильно упрощает процесс разработки
2)тесты написанные перед кодом кокретно определяют функциональность, которую требуется достичь, поэтому возникает гораздо меньше желания писать код, не относящийся к делу
3)упрщается рефакторинг кода во время написания, так как тесты уже есть
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>>>То что применимость TDD ограничивается, как минимум, формализуемостью конечного результата. G>>>>Функциональные требования вполне формальны или формализуемы. AVK>>>Любые? Это даже не смешно. G>>Это правда. AVK>Это не правда. Продолжим?
Вырывать слова из контекста это такой прием демагогии?
Всетаки приведи пример требований с неформализуемым набором функционала, чтобы по ним можно было написать код.
AVK>>>Оценка на чем основана? Опять исключительно на твоих проектах? Или на чтении книжек? G>>На проектах, моих и не только. G>>Есть факты, подтверждающие обратное — говори.
AVK>О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь
А в мои проекты TDD внесло дофига бенефитов, начиная от более качественного дизайна, заканчивая сокращением плотности ошибок на стейджинге в 10 раз и уменьшением объема рабочего кода примерно в 2 раза.
Самый кайф был гогда отали тестеру версию и через день он начал ругаться что не может найти ни одной ошибки в логике, только огрехи в интерфейсе.
AVK>>>Ясно, опять, вместо ответа на вопрос демонстрации на игрушечных примерах. G>>Там не игрушечный пример. AVK>Он игрушечный в том плане, что заранее подходит для TDD.
Чем подходит? тем что у него функциональные требования есть?
Там обычный интернет-магазин.
Вот представляю себе картину, приходит к тебе заказчик и говорит: "сделайте мне программу, которая упрощает определенные операции бухучета".
AVK>Так, еще раз — в википедии написано конкретное определение.
Думаешь в TDD определение имеет какое-то значение?
AVK>Это именно то, что нужно.
Само определение нафиг никому не нужно.
AVK>Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе.
А я не говорю что неверно, я говорю что там не то что надо.
G>>То что нужно — лучше показывать, чем описывать словами. AVK>Ясно. Я тебе так скажу — если ты даже базовые вещи не можешь сформулировать, ни о каком твоем понимании TDD говорить не приходится. И обвинения твои в том, что не понимает TDD кто то там, они выглядят, сам понимаешь.
Плохо у тебя с логикой.
На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)
Поймешь насколько легче это показать, чем объяснять.
Аналогичная картина с IoC, DDD и некоторыми другоми акронимами. Пока не не увидишь как это делается — сути не поймешь.
Здравствуйте, gandjustas, Вы писали:
G>Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится
Так, ты кажется что то не понимаешь. Формальные требования к функционалу меня не колышат. Потому что они примитивны. Меня колышет внешний дизайн фреймворка. Я же ведь не зря акцентировал на том, что собственно реализация там смешная и очевидная. Вопрос в том, каков должен быть дизайн, и как, не имея этого дизайна, написать тесты. Вот это вопрос из вопросов.
G>, так что не подходит.
Подходит.
G>А второй — что?
UI настроек решарпера.
G>Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями.
Можно и показать. Как с тестами быть?
AVK>>Направление эволюции дизайна. G>"некая функциональность должна стать удобнее" какое направление эволюции дизайна дает?
В направлении упрощения использования этой функциональности и увеличения количества покрываемых сценариев. Это если у тебя заказной софт, тогда ты можешь выдаивать из заказчика формальные требования, а потом делать умное лицо и говорить что заказчик сам виноват, что требования такие кривые. А если коробка — то никакого специального заказчика то и нет. Опять же, можно конечно кормить специяльного аналитега, но тогда получаются уродливые дизайны, где в угоду мелким фичушкам принесен и дизайн, и юзабилити, и стабильность, и целостность продукта. И все это уже совсем выбегает за рамки топика.
AVK>>То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно. G>Вообще не опеределяют, так как величины эмпирические. Невозможно задать целевое значение этой характеристики и его добиваться при разработке.
Ну вот видишь. Только у меня выводы совсем другие. Я лучше TDD отправлю в мусорку, чем ради него буду городить дизайн, который приводит к уродливому коду.
G>Кроме того понятия читаемости и легкости модификации сильно субъективны
Они в большой степени объективны.
AVK>>Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую. G>А с чего ты взял что впустую?
С того, что выхлопа 0.
G>1)тесты написанные перед кодом фиксируют требования к этому коду
Само по себе ценности не имеет.
G>, поэтому не надо держать требования в голове, что сильно упрощает процесс разработки
Помимо головы и кода есть масса различных вариантов, включая специализированный софт.
G>2)тесты написанные перед кодом кокретно определяют функциональность, которую требуется достичь
К сожалению, помимо функционала, они еще определяют и дизайн внешних контрактов. И именно в этом и проблема.
G>3)упрщается рефакторинг кода во время написания, так как тесты уже есть
С чего это он упрощается? Он усложняется. Тесты сильно мешают массированному рефакторингу, потому что ломаются не из-за ошибок, а из-за изменения дизайна контрактов. Тесты хороши, когда рефакторится реализация, а не дизайн, причем желательно подальше от тестов.
Вот именно поэтому TDD в ряде случаев и вызывает вопросы. Потому что на начальной стадии, как правило, дизайн плавает очень сильно, а TDD как раз на этой стадии тесты и навязывает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
AVK>>Это не правда. Продолжим? G>Вырывать слова из контекста это такой прием демагогии?
Прием демагогии это обвинять в вырывании из контекста, при том что я процитировал несколько уровней и закончил на конце предложения, да и контекст уж тебе то должен быть знаком, не так ли?
G>Всетаки приведи пример требований с неформализуемым набором функционала, чтобы по ним можно было написать код.
Опять за рыбу гроши. Любой пример, который я приведу, тебе не понравится. Потому что ты не понимаешь, что ситуации бывают разные. Бывает, когда ты строчишь код по линейке, а бывает, что никто на этой планете не знает, какой дизайн в итоге будет получен. Потому что иногда не конкретный функционал пытаются непременно сформировать, а руководствуются наличествующими ресурсами и полезным выхлопом от той или иной работы. Потому что всегда есть trade off по целой пачке функциональных и нефункциональных требований, и выбирать среднюю точку без учета проблем существующего и теоретически возможного дизайна кода и всего, что с ним связано сродни плеванию в потолок, эффект тот же.
А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает.
AVK>>О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь G>А в мои проекты TDD внесло дофига бенефитов, начиная от более качественного дизайна, заканчивая сокращением плотности ошибок на стейджинге в 10 раз и уменьшением объема рабочего кода примерно в 2 раза.
А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход.
Детский сад, штаны на лямках.
AVK>>Он игрушечный в том плане, что заранее подходит для TDD. G> G>Чем подходит?
Тем что TDD на нем показывает высокую эффективность.
G> тем что у него функциональные требования есть? G>Там обычный интернет-магазин.
Я не буду длинные кина смотреть, время жалко. Все это я уже миллион раз видел.
G>>>Ну рассказывай, какой функционал ты хочешь от этого контейнера? AVK>>Упрощение разработки определенного типа приложений. G>Какого?
Например типа Visual Studio.
G>Вот представляю себе картину, приходит к тебе заказчик и говорит: "сделайте мне программу, которая упрощает определенные операции бухучета".
Кроме бухучетов и интернет-магазинов есть много интересных задач. И заказчик конкретный далеко не всегда имеется.
AVK>>Так, еще раз — в википедии написано конкретное определение. G>Думаешь в TDD определение имеет какое-то значение?
Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие.
AVK>>Это именно то, что нужно. G>Само определение нафиг никому не нужно.
Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии.
AVK>>Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе. G>А я не говорю что неверно
То есть там верно? Да или нет?
G>, я говорю что там не то что надо.
Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?
AVK>>Ясно. Я тебе так скажу — если ты даже базовые вещи не можешь сформулировать, ни о каком твоем понимании TDD говорить не приходится. И обвинения твои в том, что не понимает TDD кто то там, они выглядят, сам понимаешь. G>Плохо у тебя с логикой.
Плохо. Но не у меня.
G>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок)
А чего пробовать. В инете такого навалом, можешь погуглить.
G>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами.
Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно.
G> Пока не не увидишь как это делается — сути не поймешь.
Думаю, это твоя личная особенность.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится
AVK>Так, ты кажется что то не понимаешь. Формальные требования к функционалу меня не колышат. Потому что они примитивны. Меня колышет внешний дизайн фреймворка. Я же ведь не зря акцентировал на том, что собственно реализация там смешная и очевидная. Вопрос в том, каков должен быть дизайн, и как, не имея этого дизайна, написать тесты. Вот это вопрос из вопросов.
Так ты и не говорил раньше что тебе нужна "внешняя красота".
Кстати в таком случае что-то вроде TDD работает: пишется код, в котором отражается какой API хотелось бы видеть (те самые "определенные сценарии"), а потом пишется код, который это реализует.
G>>А второй — что? AVK>UI настроек решарпера.
Только к коду это не отностится.
Может еще и руководство пользователя с помощью TDD написать?
G>>Если не получается самомтоятельно снять неопределенность, то прототип надо показывать заказчину\будущим пользователями. AVK>Можно и показать. Как с тестами быть?
В прототипе? Они там не нужны.
AVK>>>Направление эволюции дизайна. G>>"некая функциональность должна стать удобнее" какое направление эволюции дизайна дает?
AVK>В направлении упрощения использования этой функциональности и увеличения количества покрываемых сценариев. Это если у тебя заказной софт, тогда ты можешь выдаивать из заказчика формальные требования, а потом делать умное лицо и говорить что заказчик сам виноват, что требования такие кривые. А если коробка — то никакого специального заказчика то и нет.
feedback кучи юзеров гораздо лучше одного заказчика с непостоянным мнением.
Кроме того изменчивость у коробочного софта поменьше.
AVK>>>То есть, к примеру, читаемость и легкость модификации кода не определяют дизайн? Ну, мягко говоря, это очень спорно. G>>Вообще не опеределяют, так как величины эмпирические. Невозможно задать целевое значение этой характеристики и его добиваться при разработке.
AVK>Ну вот видишь. Только у меня выводы совсем другие.
Какие? С помощью каких способов ты можешь выполнит поставленные требования, типа "читаемость"?
AVK>Я лучше TDD отправлю в мусорку, чем ради него буду городить дизайн, который приводит к уродливому коду.
Повторенное дважды становится правдой?
С чего ты взял что TDD дает тебе уродливый дизайн? Скорее его отсуствие приведт к такому дизайну.
G>>Кроме того понятия читаемости и легкости модификации сильно субъективны AVK>Они в большой степени объективны.
Докажи.
AVK>>>Не путай божий дар с яишницей. Легко или сложно, это второй вопрос. Главное — ресурсы, потраченные на тесты, которые вперед, потрачены будут впустую. G>>А с чего ты взял что впустую? AVK>С того, что выхлопа 0.
Ну это твои проблемы.
G>>1)тесты написанные перед кодом фиксируют требования к этому коду AVK>Само по себе ценности не имеет.
Имеет, также как имеет ценность упомянутый тобой ниже "специализированный софт".
G>>, поэтому не надо держать требования в голове, что сильно упрощает процесс разработки AVK>Помимо головы и кода есть масса различных вариантов, включая специализированный софт.
Какой специализированный софт проверит соотвествие куска кода требованиям к нему по нажатию одной кнопки?
G>>2)тесты написанные перед кодом кокретно определяют функциональность, которую требуется достичь AVK>К сожалению, помимо функционала, они еще определяют и дизайн внешних контрактов. И именно в этом и проблема.
G>>3)упрщается рефакторинг кода во время написания, так как тесты уже есть AVK>С чего это он упрощается? Он усложняется. Тесты сильно мешают массированному рефакторингу, потому что ломаются не из-за ошибок, а из-за изменения дизайна контрактов. Тесты хороши, когда рефакторится реализация, а не дизайн, причем желательно подальше от тестов. AVK>Вот именно поэтому TDD в ряде случаев и вызывает вопросы. Потому что на начальной стадии, как правило, дизайн плавает очень сильно, а TDD как раз на этой стадии тесты и навязывает.
ОК, понял проблему. Она называется "нельзя вывести хороший дизайн и архитектуру из одних тестов", тесты навязывают решать проблемы локально, что может привести к тому, что за деревьями не видно будет леса.
Догматичное применение TDD и отказ от высокоуровневого проектирования — тот самый булшит, на который не стоит вестись.
Такой булшит часто появляется в словесном описании TDD, хотя мало кто такой подход использует (судя по тем же скринкастам).
G>>Всетаки приведи пример требований с неформализуемым набором функционала, чтобы по ним можно было написать код.
AVK>Опять за рыбу гроши. Любой пример, который я приведу, тебе не понравится. Потому что ты не понимаешь, что ситуации бывают разные. Бывает, когда ты строчишь код по линейке, а бывает, что никто на этой планете не знает, какой дизайн в итоге будет получен. Потому что иногда не конкретный функционал пытаются непременно сформировать, а руководствуются наличествующими ресурсами и полезным выхлопом от той или иной работы. Потому что всегда есть trade off по целой пачке функциональных и нефункциональных требований, и выбирать среднюю точку без учета проблем существующего и теоретически возможного дизайна кода и всего, что с ним связано сродни плеванию в потолок, эффект тот же.
Ладно, адекватных примеров не будет, это я понял.
AVK>А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает.
Да, именно поэтому и придумали TDD.
AVK>>>О, я таких же как ты "фактов" — легко. Мои проекты говорят, что TDD привносит только проблемы и лишнюю трату ресурсов, давая на выходе крошечный бенефит. Твоя очередь G>>А в мои проекты TDD внесло дофига бенефитов, начиная от более качественного дизайна, заканчивая сокращением плотности ошибок на стейджинге в 10 раз и уменьшением объема рабочего кода примерно в 2 раза. AVK>А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход.
Из этого только вывод что ты не сумел применить TDD.
AVK>Именно. Обычный интернет магазин, с которым заранее почти все ясно. Только не все проекты по уровню R&D интернет магазины.
Ну да, ентерпрайз + веб по разным подсчетам занимают от 80% до 95% разработки, а они все не очень далеко ушли от тех же интернет-магазинов.
G>>Также стоит посмотреть начало серии mvc storefront http://www.asp.net/learn/mvc-videos/ G>>А также http://ayende.com/hibernating-rhinos.aspx ролик под номером 1. AVK>Я не буду длинные кина смотреть, время жалко. Все это я уже миллион раз видел.
Судя по твоим постам — ни разу.
G>>>>Ну рассказывай, какой функционал ты хочешь от этого контейнера? AVK>>>Упрощение разработки определенного типа приложений. G>>Какого? AVK>Например типа Visual Studio.
Там уже придумали MEF, тебе он не подходит? Чем не подходит? Опиши сценарии в которых ты хочешь свой контейнер применять.
AVK>>>Так, еще раз — в википедии написано конкретное определение. G>>Думаешь в TDD определение имеет какое-то значение? AVK>Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие.
А ты перечитай топик сначала, я уже десяток раз описывал TDD.
AVK>>>Это именно то, что нужно. G>>Само определение нафиг никому не нужно. AVK>Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии.
См коммент выше.
AVK>>>Либо ты соглашаешься с тем, что написано там все верно, либо свои притензии к источнику определения оставляешь при себе. G>>А я не говорю что неверно AVK>То есть там верно? Да или нет?
Может быть и верно, я неочень внимательно читал.
G>>, я говорю что там не то что надо. AVK>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься?
Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.
G>>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок) AVK>А чего пробовать. В инете такого навалом, можешь погуглить.
Ну напиши словами, или дай ссылку на википедию где это описано
G>>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами. AVK>Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно.
И люди сразу же все понимали и начинали применять?
G>> Пока не не увидишь как это делается — сути не поймешь. AVK>Думаю, это твоя личная особенность.
Ну да, а то чт регулярно темы на форуме возникают, так это люди от нечего делать пишут.
Здравствуйте, gandjustas, Вы писали:
G>Ладно, адекватных примеров не будет, это я понял.
В реальных условиях, подобных тем, что описал AVK, примеры для TDD нужно подбирать очень-очень специально. Проблема в том, что "хороший дизайн" подразумевает подготовку к определённым будущим изменениям в требованиях. Тогда как TDD предполагает дизайн по уже состоявшимся изменениям. Противоречие не устранимое в принципе, как ты ни "понимай TDD". Понимаешь ли, какой момент, для хорошего архитектора (дизайнера) неготовность дизайна к модификациям требований — трагедь (термин шуточный, но на самом деле я не шучу), а для TDD-guy, судя по всему — норма жизни. Всё нормально, но второй подход априори дороже. Больше того, TDD по самой своей сути ведёт к плохому дизайну чаще, чем к хорошему, то есть влечёт удорожание в квадрате. Хотя все при деле, выхлопа очень много, но машина не едет.
AVK>>А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает. G>Да, именно поэтому и придумали TDD.
Ага, только придумали его ещё и предполагая плотное взаимодействие с заказчиком, что вообще невозможно, например, в рамках "коробки". Ну не приведёшь же ты к себе тыщу пользователей, правда? А с другой стороны, эти самые пользователи, встретив неудачную реализацию чего-то даже и не скажут об этом.
AVK>>А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход. G>Из этого только вывод что ты не сумел применить TDD.
Из этого только вывод, что ты безуспешно попытался выступить пропонентом технологии ради технологии.
AVK>>Именно. Обычный интернет магазин, с которым заранее почти все ясно. Только не все проекты по уровню R&D интернет магазины. G>Ну да, ентерпрайз + веб по разным подсчетам занимают от 80% до 95% разработки, а они все не очень далеко ушли от тех же интернет-магазинов.
Ты не прав, нужно написать 99%. Так внушительнее. Сам же знаешь, чем дальше аргумент отстоит от предмета спора, тем внушительнее должна быть формулировка.
G>>>Также стоит посмотреть начало серии mvc storefront http://www.asp.net/learn/mvc-videos/ G>>>А также http://ayende.com/hibernating-rhinos.aspx ролик под номером 1. AVK>>Я не буду длинные кина смотреть, время жалко. Все это я уже миллион раз видел. G>Судя по твоим постам — ни разу.
Обоснуй. А то вот я сделал прямо противоположный вывод из высказываний AVK. Ну что, сразимся имхой против имхи?
AVK>>Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие. G>А ты перечитай топик сначала, я уже десяток раз описывал TDD.
Ты лучше сам скомпилируй краткое определение для TDD (заодно поймешь, может быть, почему даже сам термин сей содержит глубокое внутреннее противоречие). А то, как показывает суровая практика, чем сильнее пропонент отказывается от выдачи определения, тем больше вероятность, что на самом деле он где-то пытается поставить лошадь позади телеги или поделить на нуль. Потому и отказывается от определения — много противоречий всплывёт. Гораздо проще обвинять окружающих в безмозглости.
AVK>>>>Это именно то, что нужно. G>>>Само определение нафиг никому не нужно. AVK>>Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии. G>См коммент выше.
Не описание, а "определение". Слона можно долго описывать, но где гарантия, что ты описал не один только хвост? Так что, давай по-порядку: сначала определение, потом описание. А не то определениями я займусь... Бу-га-га.
AVK>>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься? G>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD.
Не юли. Ты просто не знаешь толком определения TDD, потому и не можешь сравнить одно с другим.
G>>>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок) AVK>>А чего пробовать. В инете такого навалом, можешь погуглить. G>Ну напиши словами, или дай ссылку на википедию где это описано
Не надо подменять предмет обсуждения.
G>>>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами. AVK>>Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно. G>И люди сразу же все понимали и начинали применять?
Это только для икспиистов школы Agile постижение IoC нуждается в глубоком озарении. Я даже знаю почему — из-за того, что он нарушает LSP. Гы-гы.
G>>> Пока не не увидишь как это делается — сути не поймешь. AVK>>Думаю, это твоя личная особенность. G>Ну да, а то чт регулярно темы на форуме возникают, так это люди от нечего делать пишут.
А не фиг детям мозги пудрить чепухой. Сначала паттерны, потом TDD, потом Agile, все как одна — потаённые практики, доступные посвящённым. На поверку пшик, но чтобы был "пшик" нужно же воздуха накачать!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>Ладно, адекватных примеров не будет, это я понял.
ГВ>В реальных условиях, подобных тем, что описал AVK, примеры для TDD нужно подбирать очень-очень специально. Проблема в том, что "хороший дизайн" подразумевает подготовку к определённым будущим изменениям в требованиях. Тогда как TDD предполагает дизайн по уже состоявшимся изменениям.
Ну-ну, и как ты подготовишь к будущим именениям? Я знаю только один способ: делать маленькие слабосвязные компоненты и писать меньше кода. TDD обеспечивает и то и другое.
Специально дизайнить с расчетомо на изменения не стоит ибо получится монстр.
ГВ>Противоречие не устранимое в принципе, как ты ни "понимай TDD".
Это ты сам придумал противоречие.
AVK>>>А архитект, который по предельно формальным требованиям формирует единственно верный дизайн, который потом девелоперы реализуют строго в рамках спецификаций за строго определенное время — такое в основном только в книжках бывает. G>>Да, именно поэтому и придумали TDD.
ГВ>Ага, только придумали его ещё и предполагая плотное взаимодействие с заказчиком, что вообще невозможно, например, в рамках "коробки".
С чего ты взял?
ГВ>Ну не приведёшь же ты к себе тыщу пользователей, правда? А с другой стороны, эти самые пользователи, встретив неудачную реализацию чего-то даже и не скажут об этом.
Еще как скажут. Community своего продукта лучше создавать с первых версий.
Или ты думаешь что в принципе можно придумать программу, сделать её с первого раза удачную, выкатить на рынок и вообще не париться по поводу того что думают пользователи?
AVK>>>А в моих проектах TDD сильно увеличил затраты ресурсов и резко снизил скорость эволюции дизайна в процессе разработки. Твой ход. G>>Из этого только вывод что ты не сумел применить TDD. ГВ>Из этого только вывод, что ты безуспешно попытался выступить пропонентом технологии ради технологии.
Логика на гране фантастики.
AVK>>>Они имеет значение в этом топике. Потому что обсуждать что то, что ты даже вчерне описать не можешь — глупое и бессмысленное занятие. G>>А ты перечитай топик сначала, я уже десяток раз описывал TDD.
ГВ>Ты лучше сам скомпилируй краткое определение для TDD (заодно поймешь, может быть, почему даже сам термин сей содержит глубокое внутреннее противоречие).
А зачем оно надо? Чем какое-то определение поможет?
ГВ>А то, как показывает суровая практика, чем сильнее пропонент отказывается от выдачи определения, тем больше вероятность, что на самом деле он где-то пытается поставить лошадь позади телеги или поделить на нуль. Потому и отказывается от определения — много противоречий всплывёт. Гораздо проще обвинять окружающих в безмозглости.
Еще один умный. Тогда давай напиши определение завязывания шнурков, которое что-либо говорит о самом процессе завязывания.
AVK>>>>>Это именно то, что нужно. G>>>>Само определение нафиг никому не нужно. AVK>>>Конечно. Тогда так классно получится спорить. Всегда ведь можно сказать, что собеседник TDD не понимает. Еще бы, ведь что там у тебя в мозгах одному богу известно, а поделиться этим с окружающими ты не в состоянии. G>>См коммент выше.
ГВ>Не описание, а "определение". Слона можно долго описывать, но где гарантия, что ты описал не один только хвост? Так что, давай по-порядку: сначала определение, потом описание. А не то определениями я займусь... Бу-га-га.
Ты лучше образованием займись.
AVK>>>Что значит не то что надо? А что надо? И почему не то что надо? Потому что то, что там написано напрямую опровергает твои заявления, но прямо обвинить в том, что там вранье, ты боишься? G>>Да мне читать лениво что там написано, мне достаточно того что я успешно применяю TDD. ГВ>Не юли. Ты просто не знаешь толком определения TDD, потому и не можешь сравнить одно с другим.
Я тоже самое говорил, я не знаю определение TDD, от которого есть толк.
И выдумывать его абсолютно нет желания.
G>>>>На доуге попробуй описать словами процесс завязывания шнурков бантиком. (как вариант — наматывание портянок) AVK>>>А чего пробовать. В инете такого навалом, можешь погуглить. G>>Ну напиши словами, или дай ссылку на википедию где это описано ГВ>Не надо подменять предмет обсуждения.
Есть вещи которые проще показать, чем описывать. Когда это поймешь не будешь писать тот бред, который написан выше.
G>>>>Аналогичная картина с IoC, DDD и некоторыми другоми акронимами. AVK>>>Не надо свои проблемы переносить на всех остальных. Что такое IoC мне неоднократно удавалось без каких либо проблем, на пальцах, объяснять людям за 5 минут. Концепция примитивна как 5 пальцев, проще придумать сложно. G>>И люди сразу же все понимали и начинали применять? ГВ>Это только для икспиистов школы Agile постижение IoC нуждается в глубоком озарении. Я даже знаю почему — из-за того, что он нарушает LSP. Гы-гы.
И где он нарушает LSP?
Пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
И по-русски:
Таким образом, идея Лисков о "подтипе" дает определение понятия замещения — если S является подтипом T, тогда объекты типа T в программе могут быть замещены объектами типа S без каких либо изменений желательных свойств этой программы
Здравствуйте, 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.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, 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 контейнер его нарушает.
В определении нету ни слова о проверке времени типа.
Здравствуйте, 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.: Винодельческие провинции — это есть рулез!
Здравствуйте, 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>>
Здравствуйте, 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>>
Здравствуйте, Геннадий Васильев, Вы писали:
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-контейнера.
Пример покажешь?
Или хотябы скажи где трава такая забористая.
Здравствуйте, 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>Так я именно об этом и писал все время.
Что я писал все время?
Разве я хоть раз сказал что нельзя думать о дизайне не написав тестов? Может ссылку дашь?
Здравствуйте, 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?
Ах, пойду застрелюсь.
То что применяю — очень похоже на то что видел в скринкастах.
Здравствуйте, 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>>
Здравствуйте, 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>>
Здравствуйте, 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, я не собираюсь. Причины этого я уже называл.
Все, не могу уже. Ты определись с кем ты споришь — со мной или с википедией.
Больше не буду писать, а то опять скажешь что я тебя дураком обзываю.
Здравствуйте, 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>>
Здравствуйте, 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.: Винодельческие провинции — это есть рулез!
Пишем класс "Углы Эйлера", функциональность которых хранить поворот в углах эйлера и конвертирование в матрицу 3*3.
Написали код, после этого возникает резонное желание проверить его работоспособность.
Делать проверку вручную практически нереально. Поэтому пишем код кторый конвертирует матрицу в угол эйлера и обратно и сравнивает данные, и так на большом масиве данных, на граничных случаях, на специальных данных.
Проверяем что известные нам заренее углы поворота в УЭ дают нужные матрицы поворота.
Убедились в работоспособности, и что теперь делать с проверочным кодом ? Выкинуть , а вдруг придется чет менять через год , может оставить?
Оставляем, собственно совершенно очевидно получив "юнит тест".
Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
Здравствуйте, minorlogic, Вы писали:
M>Рассмотрим пример:
M>Пишем класс "Углы Эйлера", функциональность которых хранить поворот в углах эйлера и конвертирование в матрицу 3*3.
M>Написали код, после этого возникает резонное желание проверить его работоспособность. M>Делать проверку вручную практически нереально. Поэтому пишем код кторый конвертирует матрицу в угол эйлера и обратно и сравнивает данные, и так на большом масиве данных, на граничных случаях, на специальных данных. M>Проверяем что известные нам заренее углы поворота в УЭ дают нужные матрицы поворота.
M>Убедились в работоспособности, и что теперь делать с проверочным кодом ? Выкинуть , а вдруг придется чет менять через год , может оставить? M>Оставляем, собственно совершенно очевидно получив "юнит тест".
M>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.
Здравствуйте, Константин Б., Вы писали:
M>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
КБ>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.
Здравствуйте, Константин Б., Вы писали:
M>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
КБ>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.
А если через год увидишь новый ,более эфективный способ конвертирования? захочется попробовать , а тестов нету ... стремно как то ?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Константин Б., Вы писали:
M>>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
КБ>>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.
L>И чем это будет лучше?
Эти тесты проживут дольше. Можно рефакторить углы и код их использующий, а тесты не изменятся.
Здравствуйте, Константин Б., Вы писали:
L>>И чем это будет лучше?
КБ>Эти тесты проживут дольше. Можно рефакторить углы и код их использующий, а тесты не изменятся.
Зато они будут сложнее, на написание уйдет больше времени и будет сложнее локализовать ошибки.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Константин Б., Вы писали:
L>>>И чем это будет лучше?
КБ>>Эти тесты проживут дольше. Можно рефакторить углы и код их использующий, а тесты не изменятся.
L>Зато они будут сложнее, на написание уйдет больше времени и будет сложнее локализовать ошибки.
Тесты для кода использущего угла писать все равно придется. Сложность их будет такая же. Время потрачено будет то же. А ошибки легко локализуются по логам системы контроля версий.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Константин Б., Вы писали:
M>>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
КБ>>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.
M>А если через год увидишь новый ,более эфективный способ конвертирования? захочется попробовать , а тестов нету ... стремно как то ?
Здравствуйте, Константин Б., Вы писали:
M>>А если через год увидишь новый ,более эфективный способ конвертирования? захочется попробовать , а тестов нету ... стремно как то ?
КБ>Как это тестов нету? А интеграционные?
Мммм все зависит от интеграционных. Если они покрывают функциональность УЭ так же как и первые тесты , тогда вы писали тесты 2 раза. Если покрытие данными меньше, а это мне кажется более реалистичный вариант , то вы либо пишете тесты граничных условий и т.д еще раз , либо оставляете неоттестированный код.
Здравствуйте, Константин Б., Вы писали:
КБ>Как это тестов нету? А интеграционные?
Ну и конечно отлаживать код на интеграционных тестах для нового метода конвернирования УЭ будет сложнее. А если новый метод потребует еще и проверки новых граничных условий , а интеграционный тест не позволяет это сделать?
А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
Здравствуйте, minorlogic, Вы писали:
M>А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
Если такое произошло, значит интерфейс УЭ достаточно стабилен и можно откопать старые
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, minorlogic, Вы писали:
M>>А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
КБ>Если такое произошло, значит интерфейс УЭ достаточно стабилен и можно откопать старые
Ну мы же моделируем ситуацию, что старые тесты выкинули ?
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Константин Б., Вы писали:
КБ>>Здравствуйте, minorlogic, Вы писали:
M>>>А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
КБ>>Если такое произошло, значит интерфейс УЭ достаточно стабилен и можно откопать старые
M>Ну мы же моделируем ситуацию, что старые тесты выкинули ?
В svn'е то остались. Хотя наверное разумнее будет выкинуть эти тесты не сразу, а когда они начнут мешать.
Здравствуйте, Константин Б., Вы писали:
M>>Ну мы же моделируем ситуацию, что старые тесты выкинули ?
КБ>В svn'е то остались. Хотя наверное разумнее будет выкинуть эти тесты не сразу, а когда они начнут мешать.
"В svn'е то остались." это не выкинули , это как раз и есть самый что ни на есть юнит тест. А отчего они мешать то могут начать? какой сценарий? лежат себе, кашки не просят, запускать не требуют.
Здравствуйте, Константин Б., Вы писали:
L>>Зато они будут сложнее, на написание уйдет больше времени и будет сложнее локализовать ошибки.
КБ>Тесты для кода использущего угла писать все равно придется. Сложность их будет такая же. Время потрачено будет то же.
Нет, сложность интеграционных тестов будет гораздо сложнее и времени уйдет гораздо больше.
КБ>А ошибки легко локализуются по логам системы контроля версий.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Константин Б., Вы писали:
M>>>Ну мы же моделируем ситуацию, что старые тесты выкинули ?
КБ>>В svn'е то остались. Хотя наверное разумнее будет выкинуть эти тесты не сразу, а когда они начнут мешать.
M>"В svn'е то остались." это не выкинули , это как раз и есть самый что ни на есть юнит тест. А отчего они мешать то могут начать? какой сценарий? лежат себе, кашки не просят, запускать не требуют.
Ну например изменили интерфейс этих самых углов. Теперь два варианта 1) рефакторить юнит-тесты 2) выкинуть юнит-тесты
Здравствуйте, Константин Б., Вы писали:
M>>"В svn'е то остались." это не выкинули , это как раз и есть самый что ни на есть юнит тест. А отчего они мешать то могут начать? какой сценарий? лежат себе, кашки не просят, запускать не требуют.
КБ>Ну например изменили интерфейс этих самых углов. Теперь два варианта 1) рефакторить юнит-тесты 2) выкинуть юнит-тесты
В этом случае я бы подстраховался и хотел бы как минимум запустить старые тесты на новом интерфейсе, чтобы убедиться что ничего не поломал , ничего не забыл. Мне этот вариант кажется более выигрышным .
AndrewVK,
G>>Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится
AVK>Так, ты кажется что то не понимаешь. Формальные требования к функционалу меня не колышат. Потому что они примитивны. Меня колышет внешний дизайн фреймворка. Я же ведь не зря акцентировал на том, что собственно реализация там смешная и очевидная. Вопрос в том, каков должен быть дизайн, и как, не имея этого дизайна, написать тесты. Вот это вопрос из вопросов.
Я вот тут наткнулся про разработку IOC контейнера на основе TeDD. Это видеотрейс из 9 частей, где Daniel Cazzulino (создатель фреймворка Moq) в реальном времени лабает контейнер под названием Funq, и одним из нефункциональных требований есть перфоманс (он хочет сделать всех, и по последним тестам Funq всего-лишь в 2.5 раза медленнее чистого создания объектов), а другим — чтобы было красиво и статически типизировано (не так убого, как в Unity или, там, в Spring.net).
Хотя даже после просмотра что-то мне не нравится в TeDD. И складывается ощущение, что у kzu на момент тестов уже была достаточно чёткая картина, и он просто подгонял тесты под умственную модель, а потом и сам код. То есть, на мой взгляд, ему ничто не мешало поступить наоборот — сначала код, потом тесты. Тем не менее интересно, и вдобавок подумываю о переходе Autofac -> Funq.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Хотя даже после просмотра что-то мне не нравится в TeDD. И складывается ощущение, что у kzu на момент тестов уже была достаточно чёткая картина, и он просто подгонял тесты под умственную модель, а потом и сам код. То есть, на мой взгляд, ему ничто не мешало поступить наоборот — сначала код, потом тесты. Тем не менее интересно, и вдобавок подумываю о переходе Autofac -> Funq.
Поступать наоборот крайне неэффективно. так как написав тесты до кода ты сразу же ограничиваешь необходимый функционал и создаешь критерий завершения работы.
Про это тут написано — http://www.rsdn.ru/forum/philosophy/3435925.aspx
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
