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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Документация 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());

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

Однако это еще не все. Более важным является улучшение в сообщении об ошибке, что не удалось тест Constraint модели излучающего когда тест не пройден. ^† Например, рассмотрим этот классический тест, который не пройдёт:

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.

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