Как выполнить модульное тестирование с использованием Code Contracts

Question

Какова наилучшая практическая рекомендация для выполнения TDD с кодовыми контрактами .NET 4.0?

Полагаю, в частности, мой вопрос заключается в том, что, учитывая, что одним из аспектов TDD является разрешение самодокументируемого кода, а контракт теперь предоставляет часть документации, следует ли тестировать контракты кода так же, как и другой код?

Answer 1

Это зависит от того, как вы используете контракты и какое приложение вы разрабатываете.

Прежде всего: вы, конечно, не хотите проверять утверждения и постусловия (Contract.Assert, Contract.Assume,Contract.Ensures и Contract.EnsuresOnThrow) отдельно.Я не вижу практической пользы в этом - поскольку они уже проверены во время выполнения переписывающим устройством, вы обнаружите очень быстрые сбои даже без тестов.
Однако в хорошо протестированном приложении ни одно постусловие или утверждение не должно сработать - даже приневерные данныеТаким образом, если все ваши тесты (даже те, которые проверяют обработку недействительных данных!) Проходят без единого постусловия / утверждения-сбоя, ваши постусловия и утверждения могут рассматриваться как «проверенные».
Для этого вы можете захотеть обработатьсобытие ContractFailed с использованием «Assert.Fail» в ваших тестах.

Теперь «интересная» часть является предварительными условиями:
Вы разрабатываете библиотеку?Затем вы должны обязательно их проверить, если ваш бюджет / время это позволяет (хуже не проверять реальную логику).
Особенно, если вы используете перегрузку "Contract.Requires ", которая вызывает конкретное исключениесбои контракта, вы должны проверять их как обычную проверку параметров, используя конструкции if-throw.

Если вы не пишете библиотеку, я бы не сказал, что предварительные условия тестирования действительно необходимы - они не являются реальнымибизнес-требование, а скорее помощник для отладки.
И может быть очень скучно писать юнит-тест для каждого ArgumentNullException, который должен вызывать метод, если параметр null.
Если вы забудете этот код проверки (имеется в виду: Конкретный Contract.Requires) внутри вашего метода, вы, вероятно, забудете и о модульном тесте.Поэтому дополнительное значение, которое параметр-validation-test вносит в ваш (не библиотечный) код, очень мало по сравнению с подключенным значением.

Подводя итог: не проверяйте постусловия и утверждения.Выполните предварительные условия тестирования - но только для библиотек (и, возможно, частей вашего кода, которые используются как библиотеки).

Answer 2

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

Answer 3

Есть тесты для проверки поведения кода, как и ожидалось

Вы НЕ должны явно писать тесты для выполнения утверждений контракта.

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

Таким образом, вы хотите поймать контрацептивное исключение, если только затем выполните Asser.Fail («Требование договора не выполнено»)

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

Answer 4

Полезным инструментом для создания модульных тестов в сочетании с Code Contracts является Pex. Он анализирует ваш код и генерирует для него базовые модульные тесты. Самое замечательное в том, что он распознает и понимает кодовые контракты и поэтому адаптирует генерируемый им код тестирования.

Если у вас есть подписка MSDN, вы можете загрузить Pex / Moles в качестве инструмента, в противном случае вы можете загрузить его (не самую последнюю версию) по адресу http://research.microsoft.com/en-us/projects/pex/downloads.aspx.

Answer 5

Отличный вопрос.Простой ответ - нет.Контракты кода могут позаботиться о лишних тестах, которые не относятся к поведению системы.Если вы действительно можете достичь 100% покрытия кода, вам необходимо позаботиться о проверках isnull и т. Д., Эти проверки не обязательно должны быть в вашем наборе тестов.дополнительное преимущество заключается в том, что они будут проверяться во время компиляции вместо ожидания выполнения тестов.

Надеюсь, это поможет.