Общепринятая мудрость модульного тестирования является «не проверить код, который вы не владеете», так что в этом случае, даже если Moq мог бы сделать это (и он не может, потому что, как упомянуто Ela, он просто предоставляет поддельные реализации определенных частей интерфейса), вы не должны - вы должны признать, что DataAnnotations, предоставленный System.ComponentModel (или в зависимости от того, что было), были протестированы их автором и работают в соответствии с рекламой.
Конечно, если вы написали свой собственный пользовательский атрибут, тогда вы проверите этот код проверки аннотации в отдельном тестовом классе, который проверяет его функциональность, не зависящую от того, что она укладывается в свойство.
Кроме того, учитывая, что у вас есть Mock DbContext и EntitySet, я даже не вижу, где DataAnnotations войти в него - они будут иметь значение только в модульном тесте для реализации некоторых фактического объекта, в этом случае вы не должны находиться где-то рядом с DbContext или EntitySet - вы должны вручную создать сущность (или издевательскую) для теста под рукой. Не стесняйтесь сообщать нам, каков контекст этих тестов!
Update: Для того, чтобы иметь регрессионный тест на наличие конкретного атрибута определенного свойства, вы могли бы использовать отражение:
public void MyEntityClass_PropertyFoo_HasRequiredAttribute()
{
var prop = typeof(MyEntity).GetProperties().FirstOrDefault(p=>p.Name=="Foo");
if (prop!=null)
{
object[] attributes = prop.GetCustomAttributes(typeof(RequiredAttribute), true);
if (attributes.Length==0)
{
//someone took it out, explode your test here.
}
}
}
Я не думаю, что есть какой-либо другой надежный способ соблюдайте это требование, но опять-таки я могу ошибаться ...
Правильно, но я не тестирую, чтобы убедиться, что работа DataAnnotations работает, я тестирую, чтобы убедиться, что они присутствуют. Если кто-то должен был случайно реорганизовать атрибут '[Обязательный]', там должен быть тест где-то, который терпит неудачу, не согласны ли вы? – JHixson
@JHixson, извинения - ваш вопрос конкретно указывает: «Будут ли отменены правильные исключения проверки, если я попытаюсь сделать что-то, что явно запрещено аннотациями данных модели первого лица кода», но, возможно, я ее неправильно понял :) В любом случае - если вы хотите в основном «заблокировать», что определенное поле вашего объекта должно иметь атрибут «Обязательный», почему бы просто не использовать единичный тест с некоторым отражением? Вскоре я уточню свой ответ с некоторым кодом. –
Право, мое отсутствие понимания того, как насмешливые работы заставили меня неправильно рассказать о моем вопросе. Я не понимал, что издевательства были пустыми, и надеялся, что если метод 'SaveChanges()' должен завершиться неудачей в процессе производства из-за валидации, этот метод также должен потерпеть неудачу в тестировании.Теперь я вижу, что тесты должны быть более конкретными, чем проверка, проверяя одну конкретную причину, по которой метод должен терпеть неудачу. Отсюда Снова. – JHixson