Давайте сначала решим вашу проблему, а затем поговорим об общих принципах тестирования.
Assert.AreEqual
будет сравнивать по ссылочному равенству, а это не то, что вам нужно. То, что вы действительно хотите, это сравнить, что содержимое одинаково (я полагаю). Это можно сделать с помощью метода Enumerable.SequenceEqual
следующим образом:
Assert.IsTrue(expected.SequenceEqual(actual));
Теперь мы можем более широко поговорить о тестировании . У меня опубликовано об этом до , но я постараюсь обобщить тему здесь.
Сосредоточьтесь на поведении!
Модульное тестирование должно быть о поведении, не о деталях реализации! Это первый и самый основной принцип на мой взгляд. Он будет информировать каждое ваше решение.
Почему это так важно?
Потому что, если вы этого не сделаете, ваши тесты будут хрупкими. Изменение деталей реализации нарушит тесты, и этого не должно произойти . Ваши модульные тесты должны освободить вас, чтобы иметь возможность уверенно реорганизовывать и улучшать код. Если ваши тесты привязаны к деталям реализации, этого не произойдет, и вы всегда будете бороться с вашими тестами.
Так на что это похоже? Хорошо, давайте сравним два гипотетических теста:
[TestMethod]
public void TestThatUserInfoIsValidatedAndSaved()
{
var user = new User{Name = "Bob"};
UserService.SaveUser(user);
//Check that data access got called to see if Bob exists
//Check that validation got called
//Check that data access got called to save bob
}
[TestMethod]
public void ShouldSaveNewUser()
{
var user = new User{Name = "Bob"};
UserService.SaveUser(user);
//Check that bob was saved
}
В предыдущих двух методах один очень детализирован в тестировании конкретных деталей о методе, а другой просто тестирует намеченное поведение. Если мы изменим, как этот метод работает под капотом, то первый сломается. Тем не менее, второй тест должен продолжать работать просто отлично.
Ваши тесты должны описывать «Что» система делает, а не «Как» она это делает.
Сделайте это, и у вас будет гораздо лучший опыт модульного тестирования в долгосрочной перспективе.