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

Question

Помимо лучшей читабельности (может быть?) И возможности связывать ограничения, используя & и |, какие еще преимущества имеет модель ограничения по сравнению с классической моделью?

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

Answer 1

Я должен сказать, что я фанат "классической" модели. Мне легче формулировать мои утверждения по большей части, и мне тоже легче их читать. В коде нет ничего, что не нужно - никаких «То» и «Есть», которые звучат свободно, но не поддаются обнаружению IMO.

Это вполне может быть связано с привычностью, как и со всем остальным, но я подумал, что стоит убедить вас, что вы не единственный, кто находит классическую модель совершенно разумной:)

Сказав, что когда есть что-то, что легче выразить с помощью ограничений, имеет смысл использовать это. Это особенно верно, когда есть какое-то условие, которое может быть явно протестировано с ограничением, но где классическая модель просто использует Assert.IsTrue(condition). Ключевым моментом является то, что ограничение может дать вам больше информации, чем классическое для таких случаев.

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

Answer 2

Я не знаю, есть ли другие преимущества, кроме читабельности. Но это может быть большим преимуществом. Я считаю, что простой запуск каждого теста с Assert.That( ... ) вместо использования нескольких функций Assert облегчает визуальное сканирование утверждений в миллион раз, поскольку вам больше не нужно беспокоиться о названии функции, просто посмотрите на аргументы. 1002 *

В NUnit 2.4 оба синтаксиса (класс и ограничение) используют точно такой же код внизу. Там нет преимущества за кулисами, так или иначе. Если бы у вас действительно не было лучшего использования времени, я бы не стал переписывать тесты.

Answer 3

Документация NUnit 3 , которая вводит утверждения и сравнивает более новую модель ограничений с классической моделью, включает следующий пример:

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

  int[] array = new int[] { 1, 2, 3 };
  Assert.That(array, Has.Exactly(1).EqualTo(3));
  Assert.That(array, Has.Exactly(2).GreaterThan(1));
  Assert.That(array, Has.Exactly(3).LessThan(100));

Хотя в документе говорится, что «реального классического эквивалента» не существует, один может использовать классический синтаксис с LINQ для написания того, что я считаю эквивалентными тестами:

Assert.AreEqual(1, array.Where(x => x == 3).Count());
Assert.AreEqual(2, array.Where(x => x > 1).Count());
Assert.AreEqual(3, array.Where(x => x < 100).Count());

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

---

Однако это не вся история. Более важным является улучшение в сообщении об ошибке , которое при неудачном тесте модели ограничения выдает при сбое теста . ^{& dagger;} Например, рассмотрим этот классический тест, который не пройдёт:

int[] array = new int[] { 1, 2, 3 };
Assert.AreEqual(1, array.Where(x => x == 4).Count());

AssertionException, который выбрасывает NUnit, содержит следующее "краткое" Message:

    Expected: 1
    But was:  0

Напротив, при выражении этого теста в более новом синтаксисе модели ограничений:

Assert.That(array, Has.Exactly(1).EqualTo(4));

... NUnit возвращает Message:

    Expected: exactly one item equal to 4
    But was:  < 1, 2, 3 >

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

---

^{& dagger;} Большое спасибо @ nashwan за помощь в понимании этого важного улучшения в обмене сообщениями об ошибках, представленном в модели ограничений.

Answer 4

Я лично предпочитаю стиль Constraint Model Assert.That и использую его только сейчас. Я нахожу этот более новый стиль более читабельным и определила, что вероятность того, что «фактические» и «ожидаемые» аргументы перепутаются, гораздо меньше. (Как вы, безусловно, можете использовать Классическую модель Assert.AreEqual и т. Д., Что я видел, как это делают многие.) Это, очевидно, приводит к неудачным тестам, которые сообщают о неверных результатах.

В качестве примера, без проверки ;-), что из этого является правильным?

Assert.AreEqual(actual, expected);
Assert.AreEqual(expected, actual);