Как вы тестируете зависимые классы, которые нельзя тестировать вместе?

Question

У меня есть вопрос о том, как тестировать 2 класса, которые имеют зависимость друг от друга, но не могут быть протестированы вместе. Я не могу создать достаточно короткий пример кода, поэтому я попытаюсь объяснить его гипотетическими классами. Извините, если это слишком запутанно, но я все еще пытаюсь привести краткий пример.

В этом примере мы имеем дело с 4 различными классами: ObjectCreator, ObjectUser1, ObjectUser2 и Object. В модульных тестах для ObjectUser1 и ObjectUser2 каждый явно создает экземпляр объекта, который будет использоваться. ObjectCreator также имеет модульные тесты для обеспечения «правильной» конструкции экземпляра Object. Все юнит-тесты успешно пройдены. Теперь обнаружена ошибка в ObjectUser1, которая не была обнаружена в модульных тестах. Эта ошибка происходит из-за несовместимости между тем, как ObjectCreator создает объект, и тем, как ObjectUser1 использует его. Эта ошибка не существует в ObjectUser2. Исправление ошибки - изменить способ, которым ObjectCreator будет создавать объект. Проблема, с которой я сталкиваюсь, заключается в том, что когда я меняю ObjectCreator, все модульные тесты снова проходят, но я знаю, что новое изменение сломало ObjectUser2 (модульные тесты проходят для ObjectUser2 из-за способа, которым Object создан для модульного теста). Давайте предположим, что я не хочу использовать ObjectCreator в модульных тестах для ObjectUser1 и ObjectUser2 по причинам сложности.

Это распространенная проблема в модульном тестировании? Каков наилучший способ проверить зависимости, если они не могут быть протестированы вместе? Буду признателен за любую помощь в этом.

Answer 1

При тестировании класса В, Макет А. Таким образом, вы получите желаемые результаты от А. Но Б. все равно будет зависеть от этого.

Вы сможете тестировать модуль, как хотите. И вы сохраняете свою зависимость.

Answer 2

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

Я бы выбрал маршрут Внедрение зависимостей , чтобы отделить логику построения зависимостей от логики приложения. Однако переключение на DI-фреймворк может стать большим делом для вашего проекта. У вас есть другие доступные варианты, в том числе простой статический фабричный метод , при условии, что вы добавляете хуки в метод, чтобы заставить его возвращать то, что вам нужно для возврата.

После того, как они разделены, это простой случай насмешливого Объекта B.

Answer 3

Пожалуйста, смотрите: Цель насмешки

Answer 4

Мне кажется, что ваши объекты слишком тесно связаны и могут быть связаны с разделением. Не могли бы вы повторно использовать объект таким образом, чтобы было трудно отделить вещи, и, возможно, нужны два отдельных объекта?