Сама зависимость не является ожидаемым поведением, но действия, вызываемые зависимостью, безусловно, есть. Вы должны проверить материал, о котором знаете (вызывающий), и не тестировать материал, требующий от вас глубокого знания внутренней работы 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 или вашего макета. То, что вы хотите избежать тестирования (в основном) являются такие вещи, как:
- Порядок, в котором были названы методы
- Создание метода, или свойство общественности просто так что вы можете проверить это
- Все, что непосредственно не связаны ожидаемое поведение, которое вы тестируете
Опять же, зависимость - это то, что вы, как потребитель класса, предоставляете, поэтому вы ожидаете его использования. В противном случае нет смысла иметь эту зависимость в первую очередь.
Вы спрашиваете о названиях тестов или о том, как писать тесты? –
Кажется, что вы далеко продвигаетесь глубоко в пупке, ака «мета». Я бы рекомендовал вернуться к некоторым базовым принципам Agile, таким как «сделать простейшую вещь, которая могла бы работать», и спросить себя, почему вам нужно отделить механизм хранения ссылок от LinkedList. – kdgregory