Поехали:
Слайд 207
Brian Marick один из самых первых авторов инструмента измерения покрытия кода. Он написал широко известный монитор для программ, написанных на C и был нанят как консультант по написанию ядер для многих коммерческих инструментов измерения покрытия кода. Также он консультировал компании, использующие эти инструменты. Он писал о проблемах своей работы в статье How to Misuse Code Coverage.
Когда вы измеряете чью-либо производительность, эти люди, обычно, делают что-нибудь, чтоб выглядеть лучше. Если вы считаете, как много моих операторов тестируется, я добавлю тесты, чтоб проверять больше операторов, но это не значит, что я добавлю хорошие тесты. Покрытие не измерит качество моих тестов, не измерит то, как он спроектированы, как находят баги. Оно лишь проверит, как много операторов затронуто.
Brian увидел, что многие компании заставляли своих программистов поддерживать 100% покрытие, но их тесты не обязательно были качественными. Люди перемещали фокус с написания хороших тестов на написание тестов, дающих хорошее покрытие. Они покрывали больше строк кода, но находили меньше багов.
Измерение покрытия - плохой способ узнать, как близки вы к достижению цели. Достижение 90% покрытия ветвей не скажет вам, насколько тщательно вы провели тестирование. однако это не делает измерение покрытия ветвей бесполезным. Это лишь говорит о том, что это плохой инструмент для определения полноты тестирования.
Другой путь использования этого инструмента - узнать, какие области вашей программы не тестируются или тестируются плохо.
Тестируя снаружи, можно пропустить многие вещи. Много отчетов по покрытию говорили, что план тестирования проекта покрывает всего 35% кода. Когда вы определите, что стоит за остальными 65%, вы сможете спроектировать тесты так, что они покроют и эти пропущенные участки.
Слайд 207
Brian Marick один из самых первых авторов инструмента измерения покрытия кода. Он написал широко известный монитор для программ, написанных на C и был нанят как консультант по написанию ядер для многих коммерческих инструментов измерения покрытия кода. Также он консультировал компании, использующие эти инструменты. Он писал о проблемах своей работы в статье How to Misuse Code Coverage.
Когда вы измеряете чью-либо производительность, эти люди, обычно, делают что-нибудь, чтоб выглядеть лучше. Если вы считаете, как много моих операторов тестируется, я добавлю тесты, чтоб проверять больше операторов, но это не значит, что я добавлю хорошие тесты. Покрытие не измерит качество моих тестов, не измерит то, как он спроектированы, как находят баги. Оно лишь проверит, как много операторов затронуто.
Brian увидел, что многие компании заставляли своих программистов поддерживать 100% покрытие, но их тесты не обязательно были качественными. Люди перемещали фокус с написания хороших тестов на написание тестов, дающих хорошее покрытие. Они покрывали больше строк кода, но находили меньше багов.
Измерение покрытия - плохой способ узнать, как близки вы к достижению цели. Достижение 90% покрытия ветвей не скажет вам, насколько тщательно вы провели тестирование. однако это не делает измерение покрытия ветвей бесполезным. Это лишь говорит о том, что это плохой инструмент для определения полноты тестирования.
Другой путь использования этого инструмента - узнать, какие области вашей программы не тестируются или тестируются плохо.
Тестируя снаружи, можно пропустить многие вещи. Много отчетов по покрытию говорили, что план тестирования проекта покрывает всего 35% кода. Когда вы определите, что стоит за остальными 65%, вы сможете спроектировать тесты так, что они покроют и эти пропущенные участки.
Комментариев нет:
Отправить комментарий