Как сохранить Ваши модульные тесты простыми и изолированными и все еще гарантировать инварианты DDD?

Вы можете попробовать Построитель тестовых данных . Хороший пост от Ната Прайса .

Это может помочь, если вы не хотите идти по пути моков. Он может абстрагироваться от всех этих уродливых фабричных методов. Также вы можете попробовать подтолкнуть компоновщики для использования в вашем производственном коде.

Спасибо, Финглас за ответ. Я использую макеты в других тестах, но в первую очередь для тестирования взаимодействия, а не для настройки контекста теста. Я не был уверен, можно ли назвать такой полый объект только с необходимыми значениями имитацией и стоит ли их использовать.

Я нашел кое-что интересное и довольно близкое к проблеме на сайте xunitpatterns.com Джерарда Месароса. Он описывает запах кода, связанный с длинной и сложной тестовой установкой, как нерелевантная информация , с возможными решениями методы создания или фиктивные объекты . Я не совсем уверен в его реализации фиктивного объекта, поскольку в моем примере это заставило бы меня иметь интерфейс IBook (тьфу), чтобы реализовать фиктивную книгу с очень простым конструктором и обойти всю логику создания Factory.

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

Может быть, мы тоже сделаем Книгу конструктор частный (и Завод nested), чтобы никто не мог создать экземпляр пустая Книга, кроме Фабрики.

Частный конструктор Book является источником ваших проблем.

Если вместо этого сделать конструктор Book внутренним, фабрику не нужно вкладывать. Тогда вы можете заставить фабрику реализовать интерфейс (IBookFactory), и вы можете внедрить макет книжной фабрики в свой репозиторий.

Если вы действительно хотите убедиться, что экземпляры создаются только в реализациях книжной фабрики, добавьте в репозиторий метод, который принимает аргументы, необходимые фабрике:

public class BookRepository {

    public IBookFactory bookFactory;

    public BookRepository(IBookFactory bookFactory) {
        this.bookFactory = bookFactory;
    }

    // Abbreviated list of arguments
    public void AddNew(string title, Author author, BookStore bookStore) {
        this.Add(bookFactory.Create(title, author, bookStore));
    }

}

Две вещи:

• Используйте mock-объекты в тестах. В настоящее время вы используете конкретные объекты.

• Что касается сложной установки, то в какой-то момент вам понадобятся валидные книги. Вынесите эту логику в метод set up, который будет запускаться перед каждым тестом. Пусть этот метод создаст действительную коллекцию книг и так далее.

"Как бы вы решили проблему, когда необходимости заново создавать целый кластер объектов для того, чтобы иметь возможность протестировать простую вещь? Как бы вы разрушили эту зависимость и избавиться от всех этих атрибутов книги, которые нам не нужны в нашем тесте? С помощью макетов или заглушек?"

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

Для чистых модульных тестов макеты и заглушки определенно являются решение. Но поскольку вы собираетесь проводить больше тестов уровня интеграции, а макеты (или заглушки, или что-то еще) не решают вашу проблему, у вас действительно есть два разумных варианта:

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

• создать набор тестовых приборов . Это небольшие, но концептуально полные наборы данных для использования в ваших тестах. Обычно они хранятся в некоторой сериализованной форме (xml, csv, sql) и загружаются в начале каждого теста в вашу базу данных, чтобы у вас было действительное состояние. На самом деле это просто обычная фабрика, которая работает путем чтения статических файлов.

Если вы используете приборы, вы можете использовать подход с одним или несколькими приборами. Если вы можете обойтись одним «каноническим» набором данных для большинства ваших модульных тестов, это будет проще, но иногда это создает набор данных, в котором слишком много записей, чтобы их можно было понять, или просто не выражающий диапазон. сценариев, которые необходимо поддерживать. Некоторые проблемы требуют тщательного тестирования нескольких наборов данных.