Цели покрытия кода для API

Question

Какой номер вы бы дали тому, кто хочет получить конкретный целевой номер для покрытия кода API?

ОБНОВЛЕНИЕ: Чтобы уточнить, покрытие кода оператора / строки. Я понимаю, что конкретные цифры не имеют большого смысла, но это для ситуации, когда вы говорите людям, что конкретные цифры не имеют особого смысла, и они по-прежнему настаивают на том, чтобы получить число от вас, несмотря ни на что. Я специально написал API / SDK, потому что некоторые люди могут найти более низкие покрытия кода более приемлемыми для программного обеспечения уровня приложений / графического интерфейса пользователя, в отличие от библиотек, где доступно больше интерфейсов.

Answer 1

Если вы на PHP, 80% - хорошая рекомендация: http://jordionsoftware.blogspot.com/2009/09/code-coverage-targets.html

Answer 2

Вы можете получить некоторые инструменты покрытия кода, чтобы предоставить вам «покрытие функции», например, была ли выполнена функция или нет. Я бы настаивал на том, что каждая функция в API была покрыта.

Охват строк внутри реализации API - это другой вопрос. В соответствии с передовой практикой необходимо обеспечить охват 70–80% на основе строк или утверждений и общего размера.

Answer 3

Просто забудьте о покрытии кода. Это просто число и не должно быть в центре внимания при тестировании кода. Сценарии должны быть в центре внимания, а затем, высокое качество API. Я знаю, что это может звучать риторической ерундой, но вы должны изменить свое мышление с покрытия кода на сценарии: тестируете ли вы множество сценариев, которые ваш API намеревается обработать?

Покрытие кода будет полезно для определения того, что вы пропускаете некоторые сценарии, и если вы напишите много хороших сценариев, у вас будет почти 100% охват, но, опять же, это просто число, и оно не должно быть вашим фокусом. 1003 *

С уважением

Answer 4

Посмотрите на C.R.A.P. - он сочетает в себе покрытие с анализом сложности. Существует реализация Crap4J , если вы Java. Мы собираем Crap4Net, о котором мы пишем здесь:

http://www.atalasoft.com/cs/blogs/insertqualityhere/archive/2008/03/28/crap4j-port-to-net.aspx

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

Answer 5

Я бы дал им совет, что им нужно изучить части своего API, чтобы определить, какие из них практически несущественны и требуют не более 20%, а какие являются сверхкритическими и требуют> 90%.

Answer 6

Конкретные числа не имеют особого смысла, на самом деле.

Если есть 14 эквивалентных случаев, будет ли ваше тестирование более ошибочным, если вы не тестируете все 14? Что делать, если у вас есть проверка границ, которую невозможно потерпеть неудачей (в тех случаях мне нравится создавать описательные исключения, которые затем отправляются нашим сотрудникам по электронной почте)?

Лучше просто убедиться, что все логические пути покрыты.

Более подробный ответ см. в этом (очень похожем) вопросе .