Как (стратегия) для модульного тестирования свойств (получить / установить) в стиле BDD? - PullRequest
Новая
       36

Как (стратегия) для модульного тестирования свойств (получить / установить) в стиле BDD?

3 голосов
/ 09 октября 2009

У меня есть класс (из многих), у которого есть свойства. У некоторых есть логика, а у некоторых нет. Предполагая, что я хочу проверить эти свойства, как мне это сделать?

Недавно меня заинтересовал стиль BDD для создания модульных тестов.

см. здесь и здесь .

Так что я бы сделал настройку контекста - в основном создаю SUT и загружаю все, что нужно. Затем в каждом наблюдении (методе тестирования) я проверял бы, что конкретное свойство содержит то, что оно должно содержать.

Вот мой вопрос. Если SUT имеет 20 свойств, тогда я должен создать 20 наблюдений / тестов? Могло бы быть больше, если бы одно из свойств содержало более интересную логику, я думаю. 

[Observation]
public void should_load_FirstName()
{
    Assert.Equals<string>("John", SUT.FirstName);
}

[Observation]
public void should_load_LastName()
{
    Assert.Equals<string>("Doe", SUT.LastName);
}

[Observation]
public void should_load_FullName()
{
    Assert.Equals<string>("John Doe", SUT.FullName);
}

Но будет ли лучше объединить простые в одном наблюдении? 

[Observation]
public void should_load_properties()
{
    Assert.Equals<string>("John", SUT.FirstName);
    Assert.Equals<string>("Doe", SUT.LastName);
    Assert.Equals<string>("John Doe", SUT.FullName);
}

Или что, если бы я использовал пользовательский атрибут (который может быть применен к методу несколько раз). Так что я могу сделать что-то вроде: 

[Observation(PropertyName="FirstName", PropertyValue="John")]
[Observation(PropertyName="LastName", PropertyValue="Doe")]
[Observation(PropertyName="FullName", PropertyValue="John Doe")]
public void should_load_properties()
{
}

Ответы [ 2 ]

4 голосов
/ 09 октября 2009

Как правило, вы должны стремиться иметь только одно логическое утверждение на тест. Отличная книга xUnit Test Patterns содержит хорошее обсуждение этого вопроса, но существенным моментом является то, что он облегчает понимание того, где происходит нарушение, если есть только одна причина, по которой тест может не пройти. Это, вероятно, более актуально для регрессионного тестирования, чем BDD, хотя ...

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

Более центральным принципом xDD (TDD, BDD и т. Д.) Является то, что тесты должны действовать как Исполняемые спецификации . Другими словами, это должно быть сразу видно, когда вы смотрите на тест не только что тестируется , но также почему ожидаемое значение такое, как есть. В ваших примерах не очень понятно, почему ожидается, что SUT.FirstName будет "Джон", а не, скажем, "Джейн".

Если это вообще возможно, я бы написал эти тесты, чтобы использовать Производные значения вместо жестко заданных значений.

Для доступных для записи свойств я часто пишу тесты, которые просто проверяют, что получатель возвращает значение, присвоенное установщику.

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

Такие тесты могут быть инкапсулированы в повторно используемый тестовый код, который инкапсулирует общие тестовые идиомы. В настоящее время я работаю над библиотекой , которая может сделать именно это .

0 голосов
/ 13 апреля 2010

Посмотрите на другой синтаксис SubSpec (пример [Specification]) - в этом случае каждый из Assert s в конце представляет отдельное выполнение теста. Первоначально я считал синтаксис злоупотреблением лямбда-выражением, но теперь мне нравится это.

...