Насколько “достаточное” покрытие кода?

https://softwareengineering.stackexchange.com/questions/1380

16-10-2019
|

Вопрос

Мы начинаем продвигать охват кода здесь, на моей работе, и это заставило меня задуматься....Какого объема покрытия кода достаточно?

Когда вы достигнете точки уменьшения отдачи от покрытия кода?В чем разница между хорошим охватом и недостаточным?Зависит ли это от типа проекта, который вы создаете (например, WPF, WCF, Mobile, ASP.NET) (Это классы C #, которые мы пишем.)

Решение

Мы стремимся как минимум 70%. На вещах, которые легче проверить (например, структуры функциональных данных), мы стремимся к 90%, и большинство людей стремятся как можно ближе к 100%. На вещах, связанных с WPF и другими рамками, которые очень трудно проверить, мы получаем гораздо более низкий охват (всего лишь 70%).

Другие советы

Я считаю, что охват кода только плохая метрика. Легко произвести тонны бесполезных тестов, которые покрытие Код, но не проверяйте, например, не проверяйте вывод или не тестируйте кромки. Покрытие кода просто означает, что он не бросает исключение, а не то, что это правильно. Вам нужны качественные тесты- количество не так важно.

«Достаточно», когда вы можете внести изменения в свой код с уверенностью, что вы ничего не ломаете. В некоторых проектах это может быть 10%, на других, это может быть 95%.

Это почти никогда не достигает 100%. Однако иногда попытка получить 100% покрытие кода может быть отличным способом удалить Cruft из базы кода. Не забывайте, что есть два способа увеличения покрытия кода - напишите больше тестов или взять код. Если код не покрывается, потому что его трудно проверить, есть большая вероятность, что вы можете упростить или рефактор, чтобы облегчить тестирование. Если это слишком неясно, чтобы беспокоиться, чтобы проверить, обычно есть большая вероятность, что ничто другое в коде не использует его.

Покрытие кода приближается к 100% асимптотически. Следовательно, эти последние 5%, вероятно, являются большим усилием, чем стоит, поскольку вы начинаете достигать исчезающей небольших доходов за затраченные усилия.

Покрытие есть а Метрика, чтобы следить, но это не должно быть конечной целью. Я видел (и по общему признанию написано!) Много кода с высоким покрытием - 100% охват (TDD, конечно), пока:

ошибки все еще появляются
Дизайн все еще может быть бедным
Вы действительно можете убить себя, стреляя для какой -то произвольной цели покрытия - выберите свои битвы: P

Есть «Путь Testivus» вход Это я думаю, что это уместно обратить здесь :)

Только 20% большинства кодов будет работать в 80% времени. Анкет Анализ покрытия кода не очень полезен, если только в сочетании с Звоните в график Чтобы определить, что нужно проверить больше всего. Это говорит вам, где могут быть ваши кромки. Вы можете придумать 100 тестов только для этих краевых случаев, которые составляют менее 5% фактического кодекса.

Таким образом, убедитесь, что охватите 100% из 20%, которые определяют критические пути, и, по крайней мере, 50% остальных (в соответствии с графом вызовов). Это должно дать вам (примерно) 70% - 75% общего покрытия, но он варьируется.

Не сжигайте время, пытаясь получить более 70% общего покрытия, оставляя критические случаи без чеков.

Используйте покрытие в качестве руководства, чтобы указать области, не протестированные. Вместо того, чтобы иметь мандат на охват, разумно понимать причину не покрытия кода. Запись причины дефицита - это хорошая дисциплина, которая позволяет сбалансировать риски.

Иногда причина меньше, чем желательна, «например, не хватило времени», но может быть в порядке для раннего выпуска. Лучше пометить участки, чтобы вернуться для повышения в покрытии позже.

Я работаю над критическим программным обеспечением полета, где 100% охват операторов считается подходящим для некритических систем. Для более важных систем мы проверяем покрытие филиала/решения и используем метод вызов MC/DC, который иногда не является достаточно строгим.

Мы также должны убедиться, что мы также рассмотрели объектный код.

Это баланс между риском, в нашем случае очень высоким, по сравнению с стоимостью/стоимостью. Информированный выбор необходим в зависимости от риска пропустить ошибку.

Когда вы начнете рассмотреть изменения, которые повлияют на производительность времени выполнения, безопасность, гибкость или обслуживание, чтобы обеспечить большее покрытие кода, пришло время завершить поиск большего покрытия кода.

У меня есть проекты, в которых эта точка составляет 0%, потому что покрытие невозможно рассчитать, не нанося ущерба дизайну и другим проектам, где он достигает 92%.

Метрики покрытия кода полезны только для указания, если бы вы пропустили некоторые тесты. Они ничего не рассказывают о качестве ваших тестов.

Критическое программное обеспечение для пространства требует 100% покрытия операторов.

Сначала это не имеет смысла. Все знают, что полный тестовый охват не означает, что код полностью протестирован и что не так сложно получить 100% покрытие без фактического тестирования приложения.

Тем не менее, 100% покрытие является более низким пределом: хотя 100% покрытие не является доказательством программного обеспечения без ошибок, несомненно, что при меньшем покрытии код не полностью протестирован, и это просто неприемлемо для программного обеспечения для критического пространства.

Мне очень нравится ответ @RevBingo, потому что он предполагает, что борьба за 100% может привести к тому, что вы очистите или удалите неиспользуемый код.Чего я не увидел в других ответах, так это понимания того, когда вам нужен высокий охват, а когда нет.Я предпринял попытку начать это дело.Я думаю, что добавление деталей к диаграмме, подобной этой, было бы более полезным занятием, чем поиск одного номера тестового покрытия, подходящего для всего кода.

100%

Для общедоступного API, такого как коллекции java.util, который не связан с базой данных и не возвращает HTML, я думаю, что 100% покрытие является благородной начальной целью, даже если вы довольствуетесь 90-95% из-за временных или других ограничений.Увеличение охвата тестированием после завершения работы над функцией требует более детального уровня проверки, чем при других видах проверки кода.Если ваш API вообще популярен, люди будут использовать его, создавать подклассы, десериализовывать и т.д.способами, которых вы не можете ожидать.Вы же не хотите, чтобы их первым опытом было обнаружение ошибки или оплошности в дизайне!

90%

Для кода бизнес-инфраструктуры, который принимает структуры данных и возвращает структуры данных, 100% по-прежнему, вероятно, является хорошей отправной целью, но если этот код недостаточно общедоступен, чтобы вызвать много злоупотреблений, может быть, 85% все еще приемлемо?

75%

Для кода, который принимает и возвращает строки, я думаю, модульное тестирование гораздо более хрупкое, но все же может быть полезным во многих ситуациях.

50% или меньше

Я ненавижу писать тесты для функций, которые возвращают HTML, потому что он такой хрупкий.Что, если кто-то изменит CSS, JavaScript или весь возвращаемый вами блок HTML и английского, который не будет иметь смысла для конечных пользователей?Если вы сможете найти функцию, которая использует много бизнес-логики для создания небольшого количества HTML, возможно, это стоит протестировать.Но обратную ситуацию, возможно, вообще не стоит тестировать.

Около 0%

Для некоторого кода определение "правильный" - "имеет смысл для конечного пользователя". Существуют нетрадиционные тесты, которые вы можете выполнить для этого кода, такие как автоматическая проверка грамматики или проверка выходных данных HTML.Я даже настроил инструкции grep для небольших несоответствий, от которых мы обычно страдаем на работе, например, произнося "Login", когда остальная часть системы называет это "Sign In".Строго говоря, это не модульный тест, а полезный способ выявить проблемы, не ожидая конкретных результатов.

Однако, в конечном счете, только человек может судить о том, что разумно для человека.Модульное тестирование здесь вам не поможет.Иногда требуется несколько человек, чтобы судить об этом точно.

Абсолютный 0%

Это печальная категория, и я чувствую себя не таким человеком, раз пишу ее.Но в любом достаточно крупном проекте есть кроличьи норы, которые могут отнять человеко-недели времени, не принося никакой пользы бизнесу.

Я купил книгу, потому что в ней утверждалось, что показано, как автоматически моделировать данные для тестирования Hibernate.Но он тестировал только Hibernate HQL и SQL-запросы.Если вам приходится много работать с HQL и SQL, вы действительно не получаете преимущества гибернации.Существует форма базы данных Hibernate in-memory, но я не тратил время на то, чтобы выяснить, как эффективно использовать ее в тестах.Если бы у меня это было запущено, я бы хотел иметь высокое (50%-100%) тестовое покрытие для любой бизнес-логики, которая вычисляет материал путем навигации по объектному графу, заставляя Hibernate запускать некоторые запросы.Моя способность протестировать этот код прямо сейчас близка к 0%, и это проблема.Поэтому я улучшаю охват тестированием в других областях проекта и стараюсь отдавать предпочтение чистым функциям, а не тем, которые обращаются к базе данных, в основном потому, что для этих функций проще писать тесты.Тем не менее, некоторые вещи не могут или не должны быть проверены.

Я думаю, что это зависит от той части приложения, которое вы тестируете. Например, для бизнес -логики или любого компонента, включающего сложные преобразования данных, я бы нацелился на 90% (как можно больше). Я часто нашел маленькие, но опасные ошибки, просто тестируя как можно больше кода. Я бы предпочел найти такие ошибки во время тестирования, чем позволить им происходить на сайте клиента год спустя. Кроме того, преимущество высокого покрытия кода заключается в том, что он не позволяет людям слишком легко менять рабочий код, поскольку тесты должны быть соответственно адаптированы.

С другой стороны, я думаю, что есть компоненты, для которых покрытие кода менее подходит. Например, при тестировании графического интерфейса очень много времени на то, чтобы написать тест, который охватывает весь код, который выполняется при нажатии на кнопку, чтобы отправить событие на правильные компоненты. Я думаю, что в этом случае гораздо эффективнее использовать традиционный подход к выполнению ручного теста, в котором вы просто нажимаете кнопку и наблюдаете за поведением программы (открыто ли правильное диалоговое окно? Правильный инструмент выбран ?).

У меня нет такого высокого мнения об использовании покрытия кода в качестве меры для знания, когда ваш тестовый набор имеет достаточно покрытия.

Основная причина, по которой у вас есть процесс, в котором вы сначала пишете какой -то код, то некоторые тесты, а затем посмотрите на покрытие кода, чтобы выяснить, где вы пропустили тест, то именно ваш процесс нуждается в улучшении. Если вы делаете True TDD, то у вас есть покрытие кода на 100% из коробки (по общему признанию, есть некоторые тривиальности, на которые я не испытываю). Но если вы посмотрите на покрытие кода, чтобы выяснить, что тестировать, то вы, вероятно, напишите неверные тесты.

Таким образом, единственное, что вы можете сделать из покрытия кода, это то, что если он слишком низкий, у вас недостаточно тестов. Но если он высокий, нет никакой гарантии, что у вас есть все правильные тесты.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с softwareengineering.stackexchange