2012-04-21 4 views
4

Два из свойств класса имеют следующие аннотации:Как вы можете объединить данные аннотаций данных?

[Key] 
    [Column] 
    [Required] 
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)] 
    public int Id { get; set; } 


    [MaxLength(25)] 
    public string Name { get; set; } 

Я понимаю, что тестирование ключа, столбец и атрибуты, необходимые больше не юнит тест, это испытание интеграции, как это будет зависеть от основной базы данных, но как вы собираетесь тестировать атрибут MaxLength (25)?

Одна из альтернатив, о которой я могу думать, заключается в том, чтобы добавить кодовый контракт в собственность.

Update

Как было предложено, я написал следующий помощник:

public class AttributeHelper <T> where T : class 
    { 
     private Type GivenClass 
     { 
      get { return typeof (T); } 
     } 

     public bool HasAnnotation(Type annotation) 
     { 
      return GivenClass.GetCustomAttributes(annotation, true).Single() != null; 
     } 

     public bool MethodHasAttribute(Type attribute, string target) 
     { 
      return GivenClass.GetMethod(target).GetCustomAttributes(attribute, true).Count() == 1; 
     } 

     public bool PropertyHasAttribute(Type attribute, string target) 
     { 
      return GivenClass.GetProperty(target).GetCustomAttributes(attribute, true).Count() == 1; 
     } 

    } 

Я потом проверил мой помощник:

[TestMethod] 
    public void ThisMethod_Has_TestMethod_Attribute() 
    { 
     // Arrange 
     var helper = new AttributeHelper<AttributeHelperTests>(); 

     // Act 
     var result = helper.MethodHasAttribute(typeof (TestMethodAttribute), "ThisMethod_Has_TestMethod_Attribute"); 

     // Assert 
     Assert.IsTrue(result); 
    } 

Все работает отлично, за исключением того факта, что методы и свойства должны быть общедоступными, чтобы я мог использовать отражение. Я не могу думать о каких-либо случаях, когда мне приходилось добавлять атрибуты к частным свойствам/методам.

, а затем проверить на EF аннотации:

 public void IdProperty_Has_KeyAttribute() 
     { 
      // Arrange 
      var helper = new AttributeHelper<Player>(); 

      // Act 
      var result = helper.PropertyHasAttribute(typeof (KeyAttribute), "Id"); 

      // Assert 
      Assert.IsTrue(result); 
     } 
+2

Я думаю, что, проверяя, что атрибуты выполняют свою работу, а не тестируют базовую бизнес-логику, вы проверяете структуру атрибутов, и это не то, что вы должны тестировать (это уже было сделано Microsoft). Все, что вам нужно, - это ваш бизнес-уровень, чтобы убедиться, что вы передаете строку длиной 26 символов, чтобы метод возвращал некоторую проблему нарушения. 25 - это максимальная длина. Вы пишете единичный тест против вашего бизнес-уровня, передавая строку из 26 символов. Если вы хотите протестировать свой слой пользовательского интерфейса, не позволяя вводить более 25 символов, используйте Selenium для этого или подобного. – Nope

ответ

6

Я понимаю, что тестирование ключа, столбец и атрибуты, необходимые больше не юнит тест, это испытание интеграции, как это будет зависеть от основной базы данных

Как это так? Вы можете проверить, действительно ли свойство Id отмечено всеми этими атрибутами. И он попадает в категорию unit-test.

[Test] 
public void Id_IsMarkedWithKeyAttribute() 
{ 
    var propertyInfo = typeof(MyClass).GetProperty("Id"); 

    var attribute = propertyInfo.GetCustomAttributes(typeof(KeyAttribute), true) 
     .Cast<KeyAttribute>() 
     .FirstOrDefault(); 

    Assert.That(attribute, Is.Not.Null); 
} 

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

+0

Это очень полезно, я не смотрел на это так. Я думал, что мне придется проверять, что эти атрибуты работают, разговаривая с базой данных и проверяя, были ли соблюдены ограничения и проверки. Поэтому почему я сказал, что это интеграционный тест. –

+1

@CodeWorks: Конечно, интеграционный тест также проверяет наличие этих атрибутов. Но есть один главный недостаток - вы не проводите интеграционные тесты так часто, как вы делаете модульные тесты. Кроме того, им требуется намного больше времени для запуска. Поскольку маркировка ваших свойств этими атрибутами является * контрактом *, это должно быть проверено на модуле, как и любой другой контракт. Короче говоря, лучший способ - иметь два набора тестов. –

+0

Только что написал некоторые модульные тесты для предлагаемого помощника. Отражение будет работать только для публичных объектов. –

Смежные вопросы