Тестирование события PropertyChanged: действительно ли это - хороший путь?
Обратите внимание, что код Matt приведет к дополнительной запятой в конце строки; использование ОБЪЕДИНЯЕТ (или ISNULL в этом отношении) как показано в ссылке в сообщении Lance использует похожий метод, но не оставляет Вас с дополнительной запятой для удаления. Ради полноты вот соответствующие нормы из ссылки Lance на sqlteam.com:
DECLARE @EmployeeList varchar(100)
SELECT @EmployeeList = COALESCE(@EmployeeList + ', ', '') +
CAST(EmpUniqueID AS varchar(5))
FROM SalesCallsEmployees
WHERE SalCal_UniqueID = 1
2 ответа
Я использую небольшой Fluent API именно для этого. Он позволяет вам писать такие тесты:
var imageViewModel = TestHelper.GetTestImageViewModel();
imageViewModel.ShouldNotifyOn(s => s.EditModeEnabled)
When(s => s.Mode = true);
Помимо краткости, я предпочитаю этот подход, потому что он безопасен по типу - нет строковых значений, которые можно было бы синхронизировать с вашим API.
Чтобы проверить, что событие создается для большего чем одно свойство, вы можете просто написать другой тест, который сделает это. Это даст вам много тестов, но каждый будет очень маленьким, и вы избежите Рулетки утверждений .
I believe it’s a good idea to unit test the PropertyChanged event in the example you have shown. You might have written the property name string wrong which would result in a missing update.
With the WPF Application Framework (WAF) it’s very easy to write such a unit test:
Person person = new Person();
AssertHelper.PropertyChangedEvent(person, x => x.Name, () => person.Name = "Luke");