2009-08-11 2 views
2

Мне сказали не использовать детали реализации. Зависимость выглядит как деталь реализации. Тем не менее, я мог бы рассказать и о поведении.BDD/TDD: могут ли зависимости быть поведением?

Пример: LinkList зависит от механизма хранения для хранения его ссылок (например, LinkStorageInterface). Конструктор должен быть передан экземпляр реализованного LinkStorageInterface для выполнения своей работы. Я не могу сказать «shouldUseLinkStorage». Но, может быть, я могу сказать «shouldStoreLinksInStorage».

Что в данном случае верно для проверки? Должен ли я проверить, что он хранит ссылки в магазине (поведение) или вообще не тестирует это?

+0

Вы спрашиваете о названиях тестов или о том, как писать тесты? –

+0

Кажется, что вы далеко продвигаетесь глубоко в пупке, ака «мета». Я бы рекомендовал вернуться к некоторым базовым принципам Agile, таким как «сделать простейшую вещь, которая могла бы работать», и спросить себя, почему вам нужно отделить механизм хранения ссылок от LinkedList. – kdgregory

ответ

4

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

Расширение ваш пример немного, давайте представим, что наш LinkStorageInterface имеет следующее определение (Псевдо-код):

Interface LinkStorageInterface 

    void WriteListToPersistentMedium(LinkList list) 

End Interface 

Теперь, так как вы (абонент) обеспечивают конкретную реализацию этого интерфейса оно вполне разумно проверить, что WriteListToPersistentMedium() вызывается при вызове метода Save() на вашем LinkList.

тест может выглядеть следующим образом, снова используя псевдо-код:

void ShouldSaveLinkListToPersistentMedium() 

    define da = new MockLinkListStorage() 
    define list = new LinkList(da) 

    list.Save() 

    Assert.Method(da.WriteListToPersistentMedium).WasCalledWith(list) 

end method 

Вы проверили ожидаемое поведение без выполнения тестирования конкретных деталей либо вашего SUT или вашего макета. То, что вы хотите избежать тестирования (в основном) являются такие вещи, как:

  1. Порядок, в котором были названы методы
  2. Создание метода, или свойство общественности просто так что вы можете проверить это
  3. Все, что непосредственно не связаны ожидаемое поведение, которое вы тестируете

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

+0

+1: Не проверяйте выполнение. Проверьте наблюдаемый API. –

+0

@Josh Вы сказали бы, что тестирование недействительных методов, которые имеют какое-то поведение, является хорошей практикой? например, вызывая подтверждение на макет? Поскольку в методе ничего не возвращается. – User101

+0

@ User101 - Да. Это разница между тестированием на основе взаимодействия и проверкой состояния.Независимо от типа возвращаемого метода, вы все равно можете протестировать некоторое взаимодействие, которое оно имеет с зависимостью. Зависимость может быть макетной ... вам все равно. Важно то, как ваш код реагирует на различные, контролируемые поведения или зависимость. «Что произойдет, если он вернет null?» «Что произойдет, если это исключение?» и т. д. ... – Josh

1

LinkStorageInterface не является детальностью реализации - его название предлагает интерфейс к движку. В этом случае имя shouldUseLinkStorage имеет большую ценность, чем shouldStoreLinksInStorage.

Это мои 2 пенни!

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