Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharperЕсть исследования , основанные на сравнительной эффективности команд для которых, впрочем, есть критика. Прочитал, это немного из другой оперы про TDD, но критика не без основания. основной пункт критиков ошибочная measure (измеренная величина) и как следсвие неверные выводы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:02 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharperЧто полезного дает понятие эталонной ошибки? Нафига оно нужно вообще, чтобы было менее понятно что это один час? Тогда в определениях недостаточно косвенности. Хорошо, давай попробуем без эталонной ошибки. Как тогда будем мерит "затраты на исправлене последствий ошибки" если речь идёт скажем о функции синуса из стандартной библиотеки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:08 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronЧтоб тебе понятней было давай на твоём примере: Твою высокую активность на форуме - производительность можно измерить количеством строк в час. Очевидно что о полезность при этом говорить нельзя. Так понятно? примерно так же понятно, как смотри, небо голубое но говорить о пользе верблюдов при этом нельзя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:48 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronХорошо, давай попробуем без эталонной ошибки. Как тогда будем мерит "затраты на исправлене последствий ошибки" если речь идёт скажем о функции синуса из стандартной библиотеки? 1) Придумаем тест 2) Посомотрим по истории все тикеты которые приводили бы к фейлу теста, если бы он был 3) Посмотрим по истории все тикеты, закрытые как дублирующие к ним 4) Для каждого тикета просуммируем все затраты связанные с ним ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:51 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikron, единственная мера с точки зрения бизнеса может быть такая: A - доходы от разработки B - расходы на разработку в час C - риск непредвиденных расходов D - недополученные доходы М - маржа чтобы точнее оценить, надо взять десяток примерно одинаковых по скиллам команд, дать им одно задание, одни пишут с тестами, другие без тестов, изолировать друг от друга, потом считать. с точки зрения именно разработчика, с тестами разработчик может давать более контролируемые и прогнозируемые оценки разработки и сопровождения, так как знает, что большинство проблем будет отловлено авто-тестами, а не безразмерным количеством времени на отлов багов. также разработчик понимает, что написание тестов может заменить собою огромное количество технической документации, не полностью, но довольно весомую часть. поддерживать тесты в актуальном состоянии придётся, а документацию поддерживать крайне дорого. и сверять актуальность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:55 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharper1) Придумаем тест 2) Посомотрим по истории все тикеты которые приводили бы к фейлу теста, если бы он был 4) Для каждого тикета просуммируем все затраты связанные с ним 1.1) На основании каких знаний мы "придумываем тест" ? Когда мы "придумываем тест" мы знаем об ошибках извесных через системы слежения за ошибками? 1.2) Идея придумывать тесты мне совсем не нравится, потому что я запросто могу генерировать тесты из разряда "1+1==2" , доказывать что они безполезны, и на основании этого делать ложный вывод о бесполезности юнит-тестов. Мне больше нравится идея, если мы оценим уже имеющиеся тесты. Это будет объективно. 2.1) Как это практически реализовать? Вот у меня есть достип ко всем системам: JIRA/QualityCenter/Code Repository/системы автоматизации. Как измерить я пока не представляю. 4.1) Тоже не нравится, потому что учитывает затраты на "defect management". Меня же интересует "стоимость последствий ошибки" а не стоимость её исправления. Образно стоимость последсвий ошибки софта на АЭС может быть милионы человекочасов, а а стоимость её исправления 4 часа. Это разные величины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 12:46 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronа а стоимость её исправления 4 часа поиск ошибки — 9950$ исправление ошибки — 50$ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 12:49 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Хорошо, оставим пока в покое "стоимость исправлений последствий ошибки". Давайте посмотрим на "Стоимость" / TCO юнит-тестов. так-как её тоже посчитать сложно, предлогаю прикинуть от чего она зависит. ИМХО: 1) пропорционална сложности кода для юнит-теста. (Ведь кто-то его написал) - пропорционална сумарной сложность исполняемого кода во время теста минус сумарная сложность исполняемого тестируемого кода. (Можно вычеслить на основании байт-кода и принадлежности классов к тесту / коду) - пропорционална кол-ву методов в тесте: если даже сложность низкая но для теста нужно написать 30 методов, то сложность скорее высокая, и заключается в понимании материи теста. - пропорционална кол-ву классов в тесте: Обоснование см выше. 2) пропорциональна кол-ву ревизий в репозитории (И кто-то его пофиксил, непонятно почему, но затраты были) - Ревизии кототрые лежат по времени не далеко одна от другой можно считать или одной или с коеффициентом "свежести" (х0.3 например) - Ревизии кототрые лежат по времени далеко одна от другой надо считать с коефициентом "старости" (х1.5) 3) ресурсы тестов так-же влияют на сложность. например есть куча "XStream" фаилов, в кототрых внутри сложные биснес-обекты. их можно мысленно перевести в код. Значит берём их сжатый размер с фактором и добавляем к сложности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 13:40 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikron 1.1) На основании каких знаний мы "придумываем тест" ? Тесты это отражение требований. 1.2) Идея придумывать тесты мне совсем не нравится, потому что я запросто могу генерировать тесты из разряда "1+1==2" , Есть масса книжек про то, как тестировать в части из них написано, что тестировать. доказывать что они безполезны, и на основании этого делать ложный вывод о бесполезности юнит-тестов. Мне больше нравится идея, если мы оценим уже имеющиеся тесты. Это будет объективно. Тогда нам неоткуда взять данные по предотвращенным ошибкам так как тест их предотвратил. То есть они зарублены макимум на этапе CI 2.1) Как это практически реализовать? Вот у меня есть достип ко всем системам: JIRA/QualityCenter/Code Repository/системы автоматизации. Как измерить я пока не представляю. Берете требования к юниту, пишите один тест, дальше смотрите changelog, считая, что тест был с самого начала и прогоняете его по каждому изменению, дальше идете по тикетам и опросом людей выясняете сколько заняли все работы по данному тикету. 4.1) Тоже не нравится, потому что учитывает затраты на "defect management". Меня же интересует "стоимость последствий ошибки" а не стоимость её исправления. Образно стоимость последсвий ошибки софта на АЭС может быть милионы человекочасов, а а стоимость её исправления 4 часа. Это разные величины. Я думаю, все сведется к тому, что конкретные последствия будут оценены методом экспертной оценки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 14:31 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikron Так как я сам отношусь очень скептически к юниттестам задался вопросом, а как измерить полезность конкретного юниттеста? Возможно ли вообще? Или может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой? Я думаю что такой формулы не существует. Полезность мы определяем сами экспертно на основании своего видения страховки от возможных ошибок за 1 минуту до релиза. По сути мы вкладываем в разработку +20% или +30% рабочего времени но зато имеем стабильный статус релиза. Код, который покрыт юнит-тестом очень приятно рефакторить. Вы что-то поменяли. Пересобрали. Прогнали тесты. Зеленые статусы говорят о том что рефакторинг как минимум ничего не сломал. Есть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Можно даже не проверяя документировать как юзкейсы. Особенно если написать на DSL типа JBehave. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 00:19 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
привести точную разбивку по стоимости не получится. Это примерно как привести экономическое обоснование использования ООП, а не процедурного программирования. Есть устоявшиеся подходы к разработке, которым и надо следовать. Если сильно надо убедить начальство - то можно провести ссылки на майкрософтовскую документацию, где написано про юнит тестирование и как оно вовлечено в общий процесс разработки. А то если требовать экономического обоснования каждому шагу, каждой библиотеке и каждому паттерну - то никакой работы не будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 06:14 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonКод, который покрыт юнит-тестом очень приятно рефакторить. Вы что-то поменяли. Пересобрали. Прогнали тесты. Зеленые статусы говорят о том что рефакторинг как минимум ничего не сломал. Более того! Даже если разработчик не удосужился прогнать тесты перед коммитом, это сделает за него билд-сервер, и просто тупо не выпустит артефакты, сборка провалится при отказе любого теста, или в случае, если кто-то очень умный грохнул тесты, закомментировал или изменил так, что процент покрытия уменьшился. Ещё один плюс юнит-тестов, именно в методологии TDD, начиная разработку с юнит-тестов, определяются контракты и ожидания. После написания тестов, надо добиться, чтобы тесты не падали. С этого момента, реализацию можно легко делегировать на группу. И ещё один плюс юнит-тестов, о которых я писал, но повторю. Думаю ни для кого из разработчиков не секрет, что можно пользоваться дебагом в процессе разработке. Пишем что-то, компилируем, запускаем в дебаге, и либо скурпулёзно проходим по шагам реализованный алгоритм, либо ленивый стайл, тыкаем и ждём падения с точкой останова в месте падения. Проблема тут вот в чём, надо запускать весь проект с полноценным окружением. Даже возьмём крайний случай, добавили в код хитрую валидацию ИНН с расчётом контрольного числа. Как теперь проверить? Запускать всё, добираться до записи, где надо ввести ИНН и дрочить инпут? Это стиль разработки джуниора, и даже мы не позволяем джунам действовать таким образом. Пишется и отлаживается прям в юнит-тесте, никакого окружения не нужно, можно отладить очень маленький кусочек в так полюбившемся многим дебаггере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 06:29 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonЕсть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Это не посто бонус. Это колоссальный экономический эффект. Актуализация рабочей документации -- крайне дорогое удовольствие, которое ещё даже не гарантирует, что оно покрывает всю кодовую базу и не устарело. Юнит-тесты вынуждают поддерживать всё в актуальном состоянии, при чём на любой момент времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 06:32 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonКод, который покрыт юнит-тестом очень приятно рефакторить. Вы что-то поменяли. Пересобрали. Прогнали тесты. Зеленые статусы говорят о том что рефакторинг как минимум ничего не сломал. А красные — просто красивые. Реально они говорят только что сломался тест. maytonЕсть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Можно даже не проверяя документировать как юзкейсы. Часто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! Я не могу это воспринимать серьёзно, сорри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 10:30 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
StalkerSто можно провести ссылки на майкрософтовскую документацию, где написано про юнит тестирование и как оно вовлечено в общий процесс разработки. Если есть спрос то логично что микрософт продаст вам побрякушек. Но вот он подтверждает например моё мнение: John-L-MillerI was a software test developer, manager, and manager of managers at Microsoft for Windows NT 3.1, 2000, and portions of Windows XP. I am making this answer based on my experience. It does not represent the perspective or views of my employer, Microsoft. If we’d taken this approach - fix bugs a customer will hit in normal use, and ignore purely internal bugs - our quality would have suffered slightly, but I believe we could have released the same product in half the time with half as many people working on it. A test is effective if it finds bugs that would affect users. If you’re just pushing test coverage up, or trying for exhaustive testing of corner cases and internal functions (such as class definitions), you’re wasting time. Focus on the customer, fixing significant problems they will bump into, and giving them the product more quickly. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 10:46 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronЧасто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! земля круглая -- тоже миф. примерно такого уровня твоё заявление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 10:51 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronТо есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! Я не могу это воспринимать серьёзно, сорри. MSDN уже давно отстаёт от текущих публичных разработок на GutHub, зато тесты там всегда актуальные. Огромное количество публичных проектов, включая широко используемые, вообще не содержит документации, или документации там кот наплакал. Но с тестами обычно всё в порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 11:09 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttmikronЧасто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! земля круглая -- тоже миф. примерно такого уровня твоё заявление. Что земля круглая доказал Магелан. Хорошо, допустим это не миф. Ты можеш это доказать? Или хотя бы привести пример из жизни? Покажи мне хоть один продукт, где документация к нему - тексты тестоб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 11:16 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttОгромное количество публичных проектов, включая широко используемые, вообще не содержит документации, или документации там кот наплакал. Но с тестами обычно всё в порядке. Ключевое слово "публичных". Любители поразбиратся читают сам код и коментарии к / в коду. А теперь закрой код, и давай раскажи нам как по тестам понят что к чему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 11:26 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronТы можеш это доказать? доказать, что примеры кода, непосредственного использования компонентов программы, вдоль и поперёк, с ожиданием конкретного результата: что на входе, что на выходе -- это документирует код? тогда докажи что квадрат это квадрат. и примеры пожалуйста приведи. заходишь на гитхаб, открываешь любой популярный проект, и с вероятностью 90% он покрыт тестами, открываешь тесты, читаешь. я так тысячу раз делал. mikronПокажи мне хоть один продукт, где документация к нему - тексты тестоб. не цепляйся к словам, ясно что тесты это тесты, а документация это документация, поэтому тесты = документация утверждение не верное. имелось в виду, что тесты хорошо документируют модули и компоненты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:34 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronТема полезности юниттестов хотя и замусоленна в форумах и книгах, Но я пока не встречал аргументов в пользу или против них, опирающихся только на фактах. можно найти аргументы, которые опираются на логические рассуждения в основе которых находятся возможно известные факты, но этого недостаточно. Так опираются аргументы на факты или нет? Вы уж решите как-нибудь. mikronТак как я сам отношусь очень скептически к юниттестам задался вопросом, а как измерить полезность конкретного юниттеста? Возможно ли вообще? Или может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой? Вообщем, флейм он. Какие будут мысли? Мысли будут такие: тесты очевидно нужны, и здесь речь не только о юнит-тестировании. Рассчитать полезность теста невозможно. Вероятно можно найти экономическое обоснование - этим занимается экономика, а значит можно что угодно. Если вам непонятно, зачем нужны тесты, то либо вы не учавствовали в создании программ уровнем выше вывода Hello world, либо не занимались разработкой в команде (все это нормально), но как мне кажется, и, что более вероятно - вы занимаетесь неким троллингом, не зря вы про флейм что-то написали. Неужели не очевидно, детсяки разработчиков, часть бестолоковых, шальной pull request, некачественное review, и вот не бьется расчет, или то, что раньше работало перестает работать, кнопка перестала нажиматься.. Неужели вы не знаете эту фразу о двух шагах вперед и шаге назад? Вы исправляете одну ошибку, появляется новая, в том месте, где раньше все было ок. Вот мы и пришли постепенно к регрессионному тестированию Так что давайте по существу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 20:06 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronmaytonЕсть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Можно даже не проверяя документировать как юзкейсы. Часто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! Я не могу это воспринимать серьёзно, сорри. При чем здесь МСДН? Я вообще не говорил про это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 23:40 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttДаже возьмём крайний случай, добавили в код хитрую валидацию ИНН с расчётом контрольного числа. Как теперь проверить? Запускать всё, добираться до записи, где надо ввести ИНН и дрочить инпут? Это стиль разработки джуниора, и даже мы не позволяем джунам действовать таким образом. Пишется и отлаживается прям в юнит-тесте, никакого окружения не нужно, можно отладить очень маленький кусочек в так полюбившемся многим дебаггере. Мы на проекте делаем end-2-end тесты. Это круче чем unit. Это собственно симуляция работы приложения. Поднимаем симулятор MQ, Jetty, БД. Вобщем сетевые mocks. Толкаем сообщение и отслеживаем что оно проходит все точки. Благо, UI как такового нет. Просто бизнес-процессы. Даже представить сложно как много эта техника экономит денег и времени мануального тестирования. Коэффициент я точно не скажу. Но тут я-бы сказал что важнее сам факт автоматизации. Можно подвязать под Jenkins/Teamcity. Кнопку нажал и пошла симуляция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 00:13 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonМы на проекте делаем end-2-end тесты. Это круче чем unit. Это собственно симуляция работы приложения. Поднимаем симулятор MQ, Jetty, БД. Вобщем сетевые mocks. Толкаем сообщение и отслеживаем что оно проходит все точки. Благо, UI как такового нет. Просто бизнес-процессы. это уже интеграционные тесты. задача юнит-тестов эт тестировать как можно маленькие блоки: классы, методы, свойства. также юнит-тесты проверяют правильную работу исключений. не не "круче", чем unit, это другое тестирование, и не решает задач юнит-тестов :) хотя интеграционные тесты крайне полезны, так как тестируют уже именно бизнес-логику, в окружениях, близких к реальным. maytonДаже представить сложно как много эта техника экономит денег и времени мануального тестирования. скажем, мануальное тестирование можно затолкать в интеграционное, при желании :) maytonКоэффициент я точно не скажу. ну... если не можешь сказать коэффициент и доказать, значит это всё не работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 07:46 |
|
||
|
|
start [/forum/topic.php?fid=16&msg=39589849&tid=1340175]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
176ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 279ms |
| total: | 559ms |
| 0 / 0 |
