Есть ли хороший показатель полноты юнит-тестов?

Question

У меня есть класс, который мне нужен для модульного тестирования.

Для фона я занимаюсь разработкой на c # и использую NUnit, но мой вопрос более теоретический:

Я не знаю, написал ли я достаточно тестовых методов и проверил ли я все сценарии. Есть ли известный метод работы / лучшие практики / сборник правил для этого?

Что-то вроде

• "проверьте каждый метод в вашем классе ... бла бла"
• "проверить все вставки в БД ... бла бла"

(это глупый пример возможных правил, но если бы у меня в голове было что-то не глупое, я бы не стал задавать этот вопрос)

Answer 1

Есть несколько доступных метрик для модульного тестирования.Изучите как покрытие кода, так и ортогональное тестирование.

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

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

Answer 2

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

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

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

Answer 3

Единица измерения для измерения покрытия тестами в кодах называется «Покрытие кода».

Согласно Википедия :

Покрытие кода является меройиспользуется в тестировании программного обеспечения.Он описывает степень, в которой исходный код программы был протестирован.Это форма тестирования, которая непосредственно проверяет код и, следовательно, форма тестирования белого ящика.Со временем использование покрытия кода было распространено на область цифрового оборудования, современная методология проектирования которого основана на языках описания аппаратных средств (HDL)

Измерения охвата кода приведены в процентах.Различные команды и проекты устанавливают свои собственные цели покрытия тестами.Я не знаю, есть ли в отрасли число «лучших практик», но большинство моих проектов устанавливают это значение на уровне 80%.

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

Для .NET, одного из популярных инструментов для кодаохват NCover .

Answer 4

Вы можете посмотреть NCover или покрытие кода Visual Studio инструмент , которые поддерживают Nunit

Answer 5

Возможно, вы захотите посмотреть на ваше тестовое покрытие. NCover - решение для покрытия кода от разработчиков NUnit.