Comments 6
… покрытие 50% и меньше… означает тот уровень тестового покрытия, при котором результат работы приложения будет такой же, как и при отсутствии тестирования вообще. Т.е. там могут быть баги, может не быть багов...
Напомнили мне Экслера: какова вероятность встретить на улице динозавра?
Небольшой оффтоп о динозаврах и вероятностях — вероятность встретить его на улице действительно 50% — если вы собираетесь провести ровно один эксперимент ;)
Простите за занудство, но без вероятностного пространства с метрикой говорить о вероятности встретить динозавра бессмысленно, сколько бы экспериментов мы не проводили.
Аргумент о множественных экспериметах (стат. устойчивость, ЗБЧ и пр.) работает только при предположении о равнораспределенности и независимости результатов отдельных опытов. В прочих условиях этот аргумент тоже не работает.
C'est la vie.
Аргумент о множественных экспериметах (стат. устойчивость, ЗБЧ и пр.) работает только при предположении о равнораспределенности и независимости результатов отдельных опытов. В прочих условиях этот аргумент тоже не работает.
C'est la vie.
в отличии от динозавров, баги существуют =)
Не очень понял, о чем статья.
100% code coverage никаким образом не гарантирует отсутствие багов. Возьмем, к примеру, сферический код в вакууме:
Автор кода пишет два теста, где scale =100, и где scale = -100. Получаем code coverage 100%. Потом кто-то рефакторит-рефакторит, и заменяет ">" на ">=". «Code coverage» остался 100%, а баг появился.
Code coverage на больших проектах «с историей» — это скорее способ определить «куда копать» и «куда заглядывать страшно». Т.е. если тестов нет, это значит, что либо разработчики на них просто забили (нередкий случай), либо разработчики их не осилили(и такое бывает): архитектурно всё сделано так, что тестирование обходится очень дорого. В этом случае нужно принимать волевое решение выделить отдельное время на рефакторинг и/или написание тестов.
100% code coverage бессмысленен — это очень дорого, а баги всё-равно останутся. Если приложение, конечно, сложнее калькулятора :) Т.к., например, в многопоточной среде никакое покрытие кода не гарантирует отсутствие гонок или dead lock'ов.
В общем, мое мнение такое: если хочется улучшить качество разработки и/или тестирования, code coverage в этом деле может выступать лишь как очень вспомогательный инструмент. Гораздо эффективнее будет code review, статический анализ и практика закрытия багов с написанием тестов.
p.s. Такие метрики, как «code coverage», никак не зависят от языка программирования и точно есть для всех популярных.
p.p.s. «Лучше плохие тесты, чем никаких тестов» (с) Martin Fowler
100% code coverage никаким образом не гарантирует отсутствие багов. Возьмем, к примеру, сферический код в вакууме:
int method(int a, int scale)
{
if (scale > 0)
return a/scale;
else
return a;
}
Автор кода пишет два теста, где scale =100, и где scale = -100. Получаем code coverage 100%. Потом кто-то рефакторит-рефакторит, и заменяет ">" на ">=". «Code coverage» остался 100%, а баг появился.
Code coverage на больших проектах «с историей» — это скорее способ определить «куда копать» и «куда заглядывать страшно». Т.е. если тестов нет, это значит, что либо разработчики на них просто забили (нередкий случай), либо разработчики их не осилили(и такое бывает): архитектурно всё сделано так, что тестирование обходится очень дорого. В этом случае нужно принимать волевое решение выделить отдельное время на рефакторинг и/или написание тестов.
100% code coverage бессмысленен — это очень дорого, а баги всё-равно останутся. Если приложение, конечно, сложнее калькулятора :) Т.к., например, в многопоточной среде никакое покрытие кода не гарантирует отсутствие гонок или dead lock'ов.
В общем, мое мнение такое: если хочется улучшить качество разработки и/или тестирования, code coverage в этом деле может выступать лишь как очень вспомогательный инструмент. Гораздо эффективнее будет code review, статический анализ и практика закрытия багов с написанием тестов.
p.s. Такие метрики, как «code coverage», никак не зависят от языка программирования и точно есть для всех популярных.
p.p.s. «Лучше плохие тесты, чем никаких тестов» (с) Martin Fowler
Вы действительно не поняли о чем статья, у меня есть гипотеза почему: возможно Вы невнимательно ее читали, потому что повторяете те вещи, которые я там писала. Например, про то, что достижение 100% бессмысленно. И что порытие кода не связано напрямую с тем что багов нет.
Не очень поняла как связана эта статья и тесты разработчиков, когда я говорю про тесты тестировщиков…
Т.е. если тестов нет, это значит, что либо разработчики на них просто забили (нередкий случай), либо разработчики их не осилили(и такое бывает)
Не очень поняла как связана эта статья и тесты разработчиков, когда я говорю про тесты тестировщиков…
Sign up to leave a comment.
О метриках тестирования: code coverage для тестировщиков