Assert.That против Assert.True

В этом конкретном случае нет никакой разницы: вы увидите вывод примерно с таким же уровнем детализации (т. е. он говорит вам, что что-то, что, как ожидалось, должно оцениваться как true, оценивается как false). То же самое касается

Assert.IsTrue(obj.Foo);

и

Assert.That(obj.Foo, Is.True);

Ваша команда должна выбрать один стиль утверждений и придерживаться его во всех тестах. Если ваша команда предпочитает стиль Assert.That, вам следует использовать Assert.That(obj.Foo, Is.True).

Assert.That называется моделью, основанной на ограничениях. Он гибкий, потому что метод принимает параметр типа IConstraint. Это означает, что вы можете структурировать свой код с помощью более общей иерархии или структуры вызовов, передавая любой старый IConstraint. Это означает, что вы можете создавать собственные настраиваемые ограничения.

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

Итак, вы выполнили свой набор тестов на сервере CI, и, к сожалению, один из них не прошел. Открываешь логи и видишь следующее сообщение

BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false

Теперь, как бы вы поняли, что случилось с этими тестами, если вся информация, которую вы видите, заключается в том, что где-то в логическом значении AutoLoginTests ожидалось истинное значение, но было получено ложное? Теперь вам нужно перейти к исходному файлу ваших тестовых случаев и посмотреть, какое утверждение не удалось. Понимаете

Assert.True(obj.Foo)

Удивительно... до сих пор трудно сказать, что не так, только если вы разработали этот модуль 1 час назад. Вам все еще нужно углубиться в исходники тестов и, возможно, в исходники продакшна или даже отладить свой код, чтобы вы могли, наконец, понять, что вы неправильно написали переменную внутри вызова функции или использовали неправильный предикат для фильтрации зарегистрированных пользователей. Таким образом, вы заблокировали немедленную обратную связь с тестами, что очень ценно.

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

Это немного придирчиво, но ИМХО я думаю, что в этом случае Assert.That излишне многословен и поэтому может рассматриваться как запутывание. Другими словами, Assert.True немного чище, проще и проще для чтения и, следовательно, для понимания.

Чтобы быть немного более придирчивым, я бы предложил использовать Assert.IsTrue API вместо Assert.True, поскольку, опять же, ИМХО, IsTrue "читается" лучше.