Как провести модульное тестирование класса, полученного из базового класса с большим количеством зависимостей?

Question

Я пытаюсь выполнить модульное тестирование класса в некотором Java-коде, который я унаследовал.

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

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

Итак, как мне разорвать эту зависимость?

Answer 1

Наследование может быть таким хрупким.

Требуется ли наследование?Все эти «умные» вещи, которые выполняет базовый класс (например, установление соединений), - это то, что обычно обеспечивает механизм внедрения зависимостей.

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

Answer 2

Итак, у вас есть базовый класс и расширенный класс. Посмотрите, сможете ли вы реорганизовать расширенный класс, чтобы больше не расширять базовый класс, а использовать его вместо этого. Итак, где вы впервые позвонили parent::fooBar(), теперь вы звоните this.baseInstance.fooBar(). Таким образом, вы можете внедрить другой baseInstance для тестирования.

Если вам действительно нужно расширить базовый класс для переопределения чего-либо, извлеките функциональность в третий класс и сделайте расширенный класс прокси. Расширенный класс не делает ничего, кроме вызова методов третьего класса. Э.Г.

protected fooBar() {
    return this.realImplementation.fooBar();
}

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

Answer 3

У нас была похожая проблема. Множество классов и зависимостей на уровне фреймворка.Мы решили это с помощью DI

Answer 4

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