Какой идиоматический способ проверить размер коллекции в xUnit?

112

В моем наборе тестов есть тест, который выглядит примерно так:

[Fact]
public void VerifySomeStuff()
{
    var stuffCollection = GetSomeStuff();

    Assert.Equal(1, stuffCollection.Count());
}

Этот тест работает так, как я ожидал, но когда я его запускаю, xUnit выводит предупреждение:

предупреждение xUnit2013: не используйте Assert.Equal () для проверки размера коллекции.

Однако в предупреждении не предлагается никакой альтернативы, и поиск в Google приводит меня к исходному коду в xUnit для теста, который проверяет, напечатано это предупреждение.

Если Assert.Equal()это неправильный способ проверить длину коллекции, то какой?


Чтобы уточнить: я понимаю, что могу «обмануть» xUnit, чтобы он не выдавал это предупреждение, например, извлекая переменную или используя Assert.True(stuff.Count() == 1)вместо нее. Последнее просто Hacky, и бывший чувствует , как если XUnit является , например , пытаясь избежать многократных итераций цикла IEnumerable<T>, то это неправильный путь (потому что я буду получить подсказки компилятора о том , что по отдельности , если это проблема), и XUnit сам по себе никогда не должен оценивать ввод более одного раза (на самом деле он, вероятно, получит тот же ввод независимо от извлечения переменной из-за того, как работает вызов функций C #).

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

Томас Ашан
источник
если вы сохраняете stuffCollection.Count()в отдельной переменной и передаете ее в assert, выдает ли она ту же ошибку?
hellyale
Может, этот ?
Уве Кейм

Ответы:

115

Xunit предлагает быстрые исправления для большинства своих предупреждений, поэтому вы должны быть в состоянии увидеть, что он считает «правильным».

xunit

В вашем случае он хочет, чтобы вы использовали, Assert.Singleтак как вы ожидаете ровно один предмет. Если бы вы указали произвольное число, например 412, он не выдал бы вам предупреждения об использовании Count. Он будет предлагать использовать только в том Singleслучае, если вы ожидаете один предмет или Emptyесли вы не ожидаете никаких предметов.

vcsjones
источник
6
Спасибо, в этом есть смысл. FWIW, я видел это при сборке в VS Code, где быстрое действие не отображалось, поэтому на самом деле включение предложения по исправлению в предупреждающее сообщение было бы гораздо более полезным.
Томас Ашан
2
@TomasLycken - ах. Да, здесь есть проблема: github.com/xunit/xunit/issues/1423
vcsjones,
5
Я не фанат такого поведения; иногда счет 1 бывает просто случайным, и кажется менее выразительным принудительный вызов .Single (). Тест может измениться, ожидая другого подсчета, и кажется раздражающим вносить изменения для вызова совершенно другого метода, а не просто изменять число.
варгониан
2
Single - это круто для одного элемента, у меня есть 3 элемента, и я не хочу писать полный Assert.Collection, есть ли у xUnit Assert.Triple? ха-ха
Павел Чох
1
@PawelCioch согласно xunit.net/xunit.analyzers/rules/xUnit2013.html у них есть Empty, Singleи NotEmpty- если вы ожидаете, что динамическое значение xUnit2013 не должно срабатывать.
mbx
2

Я обнаружил, что это дает мне ту же ошибку:

Assert.Equal(2, vm.Errors.Count());

И его кастинг остановил появление ошибки.

Assert.Equal(2, (int)vm.Errors.Count());
devjc
источник
2
Я совершенно уверен, что это не ideomatic путь.
mbx
1

Для одного элемента в списке лучше использовать это: Assert.Single(resultList);

Боско Хан
источник
-1

У меня была такая же проблема, когда я использовал свойство Count, как показано ниже в xUnit.

введите описание изображения здесь

После этого я использую функцию Count () для сбора, она устранила мою проблему.

Бхуван Махарджан
источник
Исправлена ​​проблема, но вы по-прежнему не используете XUnit, как следовало бы!
Daniel Eisenreich
8
@DanielEisenreich, как правильно установить счетчик для определенного числа, если оно больше 1?
SomeGuyOnAComputer
@SomeGuyOnAComputer и другие 4 голоса за. Забудьте, что я сказал, я был слишком нахальным. Если он больше, у вас нет другого выбора.
Daniel Eisenreich