Assert.that vs Assert.True

Ответ 1

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

Assert.IsTrue(obj.Foo);

и

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

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

Ответ 2

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

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

Ответ 3

Итак, вы выполнили свой тестовый пакет на CI-сервере и, к сожалению, один из них не удался. Вы открываете журналы и видите следующее сообщение

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

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

Assert.True(obj.Foo)

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

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

Ответ 4

Это немного придирчиво, но IMHO Я думаю, что в этом случае Assert.That излишне подробен и поэтому может рассматриваться как обфускация. Другими словами, Assert.True немного чище, проще и легче читать и, следовательно, понимать.

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