Как я должен проверить граф объекта, созданный фабрикой в ​​модульном тесте

Question

У меня есть некоторый код, подобный следующему:

public interface IMyClass
{
    MyEnum Value { get; }
    IMyItemCollection Items { get; }
}

public class MyConcreteClassFactory : MyClassFactoryBase
{
    public override IMyClass Create(MyEnum value)
    {
        var itemBuilder = new MyRemoteItemBuilder();
        var itemCollection = new MyLazyItemCollection(itemBuilder)

        return new MyClass(value, itemCollection);
    }
}

«Настоящий» код должен заботиться только о том, чтобы фабрика возвращала экземпляр IMyClass, а не о конкретной реализации.Тем не менее, я хотел бы проверить, что фабричный класс делает то, что должен - построить конкретный граф объектов.

Должен ли я написать несколько тестов, которые вызывают метод create и проверяют свойства возвращаемого объекта? Этот вопрос , кажется, указывает на это, но применимо ли это, если мне нужно проверить несколько слоев классов и свойств для проверки графа объектов, созданного фабрикой?Не приведет ли это к тестовому коду, например:

var created = objectUnderTest.Create(MyEnum.A);
var itemBuilder = (created.Items as MyLazyItemCollection).Builder;
Assert.IsInstanceOfType(itemBuilder, typeof(MyRemoteItemBuilder));

Мне не особенно нравится удручающий created.Items, но, как я понимаю, это будет единственный способ утверждать, что фабрикаправильно создал MyLazyItemCollection, поскольку не каждый IMyItemCollection может иметь свойство builder ... И это только второй слой графика.Возможно, мне понадобится еще глубже изучить зависимости MyRemoteItemBuilder, чтобы увидеть, были ли они созданы правильно:

var service = ((created.Items as MyLazyItemCollection)
   .Builder as MyRemoteItemBuilder).Service;
Assert.IsInstanceOfType(service, typeof(MyService));

Должен ли я тестировать свою фабрику таким образом, принимая неприглядные вложенные откаты - это тесткод, в конце концов - или я должен вытащить конструкцию IMyItemCollection в другую фабрику и добавить это как зависимость к моему MyConcreteClassFactory (чтобы я мог внедрить его из тестового кода и утверждать, что значение created.Items было экземпляромсоздано моей издевательской фабрикой).Я ожидаю, что последнее быстро приведет к взрыву на фабриках и фабриках.В конце концов, пользователь MyConcreteClassFactory не должен беспокоиться о том, что он должен поставлять определенные под фабрики, если она ..?

Answer 1

Это зависит от потребностей, но мой ответ - НЕТ.

Вы никогда не должны разрабатывать свои тесты таким образом, как «Выполнение теста (или детализация)», который вначале мог бы работать очень хорошо,но через некоторое время вы будете в беде.Реализация меняется очень быстро, с каждым изменением вы вынуждены исправлять множество тестовых случаев.

Напротив, вы должны «Тестировать поведение».По сути, это означает, что вы абстрагируете все детали (конкретный класс) и тестируете кейсы, тестируя некоторые ценные сценарии, а не детали.

Мой вариант - создать кейсы «Реализация теста», тогда я делаю TDD.Но позже они должны быть подвергнуты рефакторингу с делами «Тест поведения».

Это очень важно, если вы говорите не только о количестве тестов, но и о качестве при построении реальной сети безопасности.