Цели покрытия кода для API
Какой номер вы бы дали тому, кто хочет конкретное целевое число для покрытия кода API?
ОБНОВЛЕНИЕ: Чтобы уточнить, покрытие кода оператора / строки. Я понимаю, что конкретные числа не имеют особого смысла, но это для ситуации, когда вы говорите людям, что конкретные числа не имеют особого смысла, и они по-прежнему настаивают на получении от вас числа, несмотря ни на что. Я специально написал API / SDK, потому что некоторые люди могут посчитать меньшее покрытие кода более приемлемым для программного обеспечения уровня приложений / графического интерфейса пользователя, в отличие от библиотек, где доступно больше интерфейсов.
@Elie: Спасибо, у меня не было представителя, чтобы сделать это самому.
Ответы 6
На самом деле конкретные числа не имеют особого смысла.
Если существует 14 эквивалентных случаев, будет ли ваше тестирование более подвержено ошибкам, если вы не протестируете все 14? Что делать, если у вас есть проверка границ, которая должна быть невозможной (мне нравится выдавать описательные исключения в этих случаях, которые затем отправляются по электронной почте нашим сотрудникам разработчиков)?
Лучше просто убедиться, что все логические пути покрыты.
Для более подробного ответа см. этот (очень похожий) вопрос.
Я бы посоветовал им изучить части своего API, чтобы определить, какие из них практически несущественны и требуют не более 20%, а какие - сверхкритичные и требуют> 90%.
Взгляните на C.R.A.P. - он сочетает в себе покрытие с анализом сложности. Есть реализация Crap4J, если вы Java. Мы собирали Crap4Net, о которой писали здесь:
http://www.atalasoft.com/cs/blogs/insertqualityhere/archive/2008/03/28/crap4j-port-to-net.aspx
Идея состоит в том, что вы получите хорошие цифры, если у вас есть небольшие простые методы или если у более сложных есть хороший охват.
Просто забудьте о покрытии кода. Это просто число, и оно не должно быть в центре внимания при тестировании кода. В центре внимания должны быть сценарии, а затем высококачественный API. Я знаю, что это может показаться риторической чушью, но вы должны изменить свое мышление с покрытия кода на сценарии: вы тестируете много сценариев, которые ваш API намерен обрабатывать?
Покрытие кода будет полезно для определения того, что вам не хватает некоторых сценариев, и если вы напишете много хороших сценариев, у вас будет почти 100% покрытие, но, опять же, это просто число, и вы не должны фокусироваться на нем.
С уважением
Вы можете получить некоторые инструменты покрытия кода, которые предоставят вам «покрытие функции», например, независимо от того, была ли функция выполнена. Я настаиваю на том, чтобы были охвачены все функции API.
Покрытие строк внутри реализации API - это другое дело. Хорошая практика предлагает снимать с охватом 70-80% на основе линий или утверждений и общего размера.
Если вы используете PHP, 80% кажется хорошей рекомендацией: http://jordionsoftware.blogspot.com/2009/09/code-coverage-targets.html
вы получите больше ответов, если отметите это тегом code-cover ... и там уже есть несколько похожих вопросов.