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 bool се очаква вярно, но е получено невярно? Сега трябва да отидете до изходния файл на вашите тестови случаи и да видите кое твърдение е неуспешно. Ще видиш

Assert.True(obj.Foo)

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

Мисълта ми е, че няма значение колко плавни са вашите твърдения (които също са уместни), а каква информация излагате в случай на неуспешни тестове и колко бързо можете да разберете основната причина за неуспеха, дори ако сте работили дълго време преди с тази функционалност

Това е малко придирчиво, но IMHO мисля, че в този случай Assert.That е ненужно многословно и следователно може да се разглежда като объркване. С други думи, Assert.True е малко по-чист, по-ясен и по-лесен за четене и следователно за разбиране.

За да станете малко по-придирчиви, бих предложил да използвате Assert.IsTrue API вместо Assert.True, тъй като, отново IMHO, IsTrue "чете" по-добре.