Я прошел через это, помогая пройти автоматизированное тестирование компании от scattergun / patchy до большей полезности и гораздо более высокого качества.
Я считаю, что попытка применить метрику в качестве основного фактора качества не имеет смысла.Прежде всего, это проблема людей.Вы не можете заставить кого-то поверить во что-то без причины, так же, как вы не можете волшебным образом сделать это хорошо без поддержки.
Короткий и сложный ответ заключается в том, что для повышения качества теста вам нужноотноситься к тестовому коду как к первоклассному гражданину.Люди не смогут хорошо выполнить автоматизированное тестирование, если они не могут быть проданы на нем, и им не будет оказана поддержка для улучшения своих навыков.Многие люди избегают этой проблемы, но дело в том, что автоматизированное тестирование - это трудно , и многие разработчики не «поймут это» или не примут, что это навык, которому нужно учиться;что еще хуже, многие будут молча бороться и отказываться просить о помощи.
Если не доказать свои преимущества, это приводит к тщательному тестированию, которое заставляет разработчиков думать, что тестирование бесполезно и не находит ошибок.Если разработчик рассматривает тестирование как рутинную работу и звонит по телефону, он уже думает, что оно бесполезно - оно становится самоисполняющимся пророчеством и полным трудом.По своему опыту я знаю, что нет ничего хуже, чем писать свой код, а затем писать все свои тесты, чтобы достичь цели магического освещения.К тому времени код становится не только непроверенным, но и похожим на выполнение всей школьной домашней работы в воскресенье вечером - это неинтересно.
Вам необходимо понять, почему модульное тестирование может помочь, чтохороший / правильный / понятный / обслуживаемый / и т. д.юнит тест выглядит так.Вы можете сделать это через образование, презентации, парное программирование, обзоры кода и так далее.Если вы просто установите жесткий лимит и скажете людям, что ожидаете, что они его встретят, они, вероятно, возмущаются им, а затем начинают игру с системой.Примечание: это не легко сделать!Требуется много времени, чтобы подозрительные разработчики увидели ценность и начали писать не сумасшедшие тесты.Там нет ни единого «ага» момент, на который вы можете рассчитывать.Были проведены исследования, доказывающие, что автоматизированное тестирование может быть ценным инструментом разработки, но многие разработчики являются догматичными.Некоторые просто никогда не придут к этой идее.
Я считаю, что парное программирование работает очень хорошо.Найдите изолированный компонент, который можно легко протестировать, или напишите с ним несколько тестов.Пройдите процесс написания тестов, прохождения тестов, рефакторинга тестов и рабочего кода, чтобы устранить проблемы и сделать их более читабельными.Со временем развивайте свои навыки, демонстрируя им самые распространенные приемы из набора инструментов тестирования.Со временем, попробуйте различные методы, такие как использование хороших методов именования, именованных констант, заводских методов, сборщиков тестовых данных, стиля BDD «приспособление как контекст».Покажите им, как доказать, что ошибка существует, написав провальный тест перед ее исправлением.Подчеркните наиболее важные принципы создания хороших тестов!
Конечная цель должна состоять в том, чтобы все команды разработчиков кода согласились с некоторыми практическими правилами, такими как «Чтобы подписаться, все истории должны быть соответствующим образом протестированы и пройти проверку кода.«.Если автоматическое тестирование не является ценным / выполнимым для данной части работы (например, прототипа), это на 100% хорошо, но это должно быть исключением, а не правилом.
Наличие уважаемых руководителей кода, которые будут работать со своимикоманды, чтобы это произошло, имеют первостепенное значение.Если вы не можете получить вступительный взнос от всех потенциальных клиентов, у вас есть серьезная проблема.
Вы можете расширить свой подход, используя инструменты метрик кода, такие как NDepend (или вариант для вашего языка), который предлагает такие функции, какперечисление наиболее сложного / используемого кода, который не имеет хорошего покрытия тестами, или областей, в которых не хватает покрытия, которые больше всего изменились между проверками.
Удачи.