Блог

Наша домашняя платформа использует универсальный класс DBField<T> , для эмуляции полей сущностей с базами данных , которые несовместимы с Entity Framework (например, Oracle 11 или Sybase).

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

     DBField<int?> z_intLength = 2;
    while (z_intLength <= 5)
    {
        z_intLength  ;
    }

    //[...]

    DBField<int?> z_intMaxLength = 10;
    if (z_intLength > z_intMaxLength)
    {
    }
 

Все вышесказанное прекрасно работает. Мы использовали public static implicit operator DBField<T>(T value) и public static implicit operator T(DBField<T> value) , наряду с переопределением == и другими операторами сравнения, а также реализовали IEquatable<DBField<T>> , IComparable , и IComparable<DBField<T>> .

Сейчас мы пытаемся DBField<T> пройти тесты NUnit, в которых мы довольно новички.

Примечательно, что мы пробуем свои силы с различными эквивалентами:

             string z_strComment = "Comment";
            _objOrder2.OrderComment = z_strComment;

            //[...]

            Assert.True("Comment" == _objOrder2.OrderComment);
            Assert.That("Comment", Is.EqualTo(_objOrder2.OrderComment));
            Assert.That(_objOrder2.OrderComment, Is.EqualTo("Comment"));
            Assert.Equals("Comment", _objOrder2.OrderComment);
 

Первые два утверждения проходят, а следующие два терпят неудачу.

1. По-видимому, существует разница во внутренней работе каждого утверждения. Может кто-нибудь объяснить, что это такое?
2. Точнее, отладка с точками останова, по-видимому, указывает на эти Assert.That("Comment", Is.EqualTo(_objOrder2.OrderComment)) тесты _objOrder2.OrderComment.Equals("Comment") ; я бы ожидал, что все будет наоборот. Я что-то упускаю?
3. Я это понимаю True() и Equals() старше, чем That() . Какие из них предпочтительнее в каких ситуациях?

Здесь играют 2 вещи:

1. Насколько полезно сообщение об ошибке от NUnit в случае сбоя теста
2. Какой стиль API NUnit вы используете

 Assert.True("Comment" == _objOrder2.OrderComment)
 

Если этот тест не пройдет, вы получите сообщение типа «Ожидалось верно, было ложно». Бесполезно, так как это не говорит вам, какова была ценность _objOrder2.OrderComment на самом деле.

 Assert.Equals("Comment", _objOrder2.OrderComment);
Assert.That(_objOrder2.OrderComment, Is.EqualTo("Comment"));
 

Эти два варианта эквивалентны, первый использует немного более короткий синтаксис, второй использует более расширяемую модель ограничений (например, вы можете написать свои собственные утверждения Assert.That(x, new MyConstraint(y)) ).

Если тест провалится, вы получите что-то вроде Expected "Comment", was "Actual Value" . Это немного более полезно.

 Assert.That("Comment", Is.EqualTo(_objOrder2.OrderComment));
 

Этот-наоборот. Если это не удастся, вы получите что-то вроде Expected "Actual Value", was "Comment" , что просто неправильно.

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

Прочитайте комментарий одного из разработчиков NUnit ниже о том, как они обнаружили, что пользователям Assert.That легче понять стиль.