На зависимости в модульном тестировании

Question

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

Мой вопрос.Разве модульные тесты не слишком фокусируются на зависимостях между объектами?Что вы делаете, когда ваш модульный тест не пройден, потому что зависимость, которую ваш метод использовал для вызова, больше не вызывается (проектное решение) или ваш метод вызывает другой метод или зависимость (снова проектное решение). Вы перепроектируете свои тесты?Если это так, то модульное тестирование очень мало помогает уменьшить пару и улучшить сцепление между компонентами.

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

Answer 1

Я бы посоветовал вам взглянуть на разработку через тестирование (TDD), так как я считаю, что этот метод поможет вам в решении проблем проектирования.При написании модульных тестов перед написанием рабочего кода вам нужно будет подумать о том, как сделать ваш рабочий код тестируемым.Это лучше, чем подход «тестирование позже», когда вы сначала пишете производственный код, а затем пытаетесь обойти их тестами.

Чтобы разобраться с зависимостями, подумайте о том, какие зависимости вызывают у вас проблемы.

Внешние зависимости

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

Если для вашего теста требуется база данных, то снова вы пишете интеграционный тест.Лично я создаю локальную копию базы данных на своем ПК и запускаю свои тесты на нее.

Зависимости объектов

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

Я бы также рекомендовал вам попробовать использовать фальшивую среду, такую ​​как RhinoMocks , Moq или TypeMock

Среда моделирования поможет вам устранить зависимость, например, от наличия базы данных для ваших тестов.Я лично использую TypeMock, это не дешево, но это, безусловно, самый мощный инструмент там.

Answer 2

Модульные тесты должны проверять поведение, а не реализацию. Таким образом, можно полагаться на модульные тесты при изменении реализации или при рефакторинге кода. Удаление зависимости (например, путем встраивания класса) не нарушает тест.

Тестирование реализации приводит к хрупким тестам, которые мешают при рефакторинге.

Answer 3

Если вы говорите о модульном тестировании, у вас нет никаких зависимостей, потому что модульное тестирование тестирует только один класс (Java, C ++, Ruby, Python). То, о чем вы говорите, больше похоже на интеграционное тестирование, которое отличается. Кроме того, если у вас много зависимостей, ваша связь слишком высока, что не очень хорошо, но, конечно, не всегда можно избежать.