Понимание ограничений модульного теста и помощников синтаксиса NUnit

Question

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

Мой коллега недавно поставил под сомнение точку зрения помощников по синтаксису NUnit, и я изо всех сил пытаюсь объяснить их преимущества (поскольку я сам по-настоящему не понимаю этого, за исключением того, что моя интуиция говорит, что они хорошие!). Вот пример утверждения:

Assert.That(product.IsValid(), Is.False);

Для меня это имеет полный смысл, мы говорим, что ожидаем, что значение product.IsValid() будет false. С другой стороны, мой коллега предпочел бы, чтобы мы просто написали:

Assert.That(!product.IsValid());

Он говорит ему, что это имеет больше смысла, и он может читать это легче.

Пока единственное, с чем мы можем согласиться, это то, что вы, скорее всего, получите более полезный результат, если тест не пройден по предыдущему, но я думаю, что должно быть лучшее объяснение. Я просмотрел некоторую информацию о помощниках синтаксиса (http://nunit.com/blogs/?p=44), и они имеют смысл, но я не совсем понимаю концепцию ограничений, отличную от того, что они «чувствуют» правильно.

Интересно, кто-нибудь мог бы объяснить, почему мы используем концепцию ограничений и почему они улучшают приведенные выше примеры модульных тестов?

Спасибо.

Answer 1

Я думаю, что это в основном связано с чисто английским прочтением заявления.

Первое чтение

Подтвердите, что товар действителен, является ложным

Второе чтение

Подтвердите, что товар не действителен

Я лично считаю, что первый процесс проще. Я думаю, что все зависит от предпочтений. Хотя некоторые из методов расширения интересны, они позволяют вам делать подобные утверждения:

product.IsValid().IsFalse();

Answer 2

Я вижу вашу версию лучше, чем ваши коллеги. Тем не менее, я все равно чувствовал бы себя так же комфортно:

Assert.IsFalse(product.IsValid());

Если вы можете убедить меня в том, что синтаксис Assert.That имеет объективную выгоду по сравнению с вышеизложенным, я был бы очень заинтересован :) Это может быть просто силой привычки, но я очень легко могу прочитать "Какого рода утверждение мы делаем? Теперь о чем мы утверждаем? " стиль.

Answer 3

Это все сахар. Внутренне они преобразуются в ограничения.

Из Прагматического модульного тестирования, стр. 37:

"NUnit 2.4 представил новый стиль утверждений, которые являются немного менее процедурными и допускают более объектно-ориентированную базовую реализацию. ... Например:

Assert.That(actual, Is.EqualTo(expected));

Преобразует в:

Assert.That(actual, new EqualConstraint(expected));"

Использование ограничений также позволяет вам наследовать от Constraint и создавать свои собственные пользовательские ограничения с сохранением согласованного синтаксиса.

Answer 4

Мне не нравится Assert.Так, в частности, тот факт, что его наиболее распространенный сценарий (сравнение равенства двух объектов) заметно хуже, чем «классический» синтаксис Assert.AreEqual ().

С другой стороны, я очень люблю расширения MSpec NUnit. Я рекомендую вам проверить их (или посмотреть на расширения SpecUnit, или расширения NBehave, или N Behave Spec * Единицы расширения, я думаю, что они все одинаковые).