Никогда не следует использовать статические методы, классы и синглтоны при следовании парадигме Test Driven Development

Question

Я читал, что статические методы, статические классы и синглтоны - это зло, когда вы пытаетесь реализовать модульное тестирование в своем проекте. Следуя парадигме TDD, должен ли я просто забыть о том, что они когда-либо существовали, и никогда не использовать их снова, или это нормально - иногда их использовать?

Answer 1

Никогда не говори никогда - статические классы и методы имеют свое место в вашем наборе инструментов.

Тем не менее, если класс, который вы пытаетесь изолировать и тестировать (субъект или тестируемый объект), зависит от статического класса или метода, вы не сможете написать тест, который изолирует SUT от этой статической зависимости - когда Ваш тестовый код выполняется, он все еще будет использовать статический вызов. Иногда это хорошо, но иногда вы хотите создать изолированный тест, который проверяет ТОЛЬКО логику вашего SUT без каких-либо зависимостей (обычно с помощью насмешек или аналогичных методов).

В целом, я лично использую статические классы и методы относительно экономно.

Из-за особенностей реализации Singletons они представляют аналогичную проблему для изоляции SUT для модульного тестирования. Кроме того, определенный процент разработчиков GOF считается плохой практикой. Я согласен с этим мнением, но вряд ли существует консенсус по этому вопросу. Быстрый поиск в Google, вероятно, даст вам хорошее представление о плюсах и минусах шаблона GOF Singleton.

Answer 2

1. Должны ли вы забыть, что они когда-либо существовали? Нет.
2. Должны ли вы убедиться, что их включение в ваш код выполняется таким образом, чтобы они были прозрачны для функциональности класса? Да.

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

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

Что касается статических методов, я бы сказал, что это наиболее легко тестируемые методы, которые вы могли бы написать, основываясь на условии, что вам не нужно беспокоиться о глобальном состоянии. Статические эквивалентны y = f(x), что кажется упрощенным, но лежит в основе того факта, что никакие локальные переходы состояний не могут изменить инвариант, что для данного x вы всегда получите тот же y.

Answer 3

Как и в любой практике разработки программного обеспечения, никогда не бывает однозначного решения любой ситуации. Поэтому вы никогда не должны исключать статические методы, статические классы и синглтоны. Цель TDD - сделать вашу жизнь проще, и вы заметите, что по мере того, как вы будете больше работать с TDD, ваш код будет модульным, что означает, что даже если вы используете статические методы (... и т. Д.), Ваш код все еще будет тестируемым.

Правило, которое мне нравится соблюдать: используйте все, что угодно, если ваш код легко читается и ваш дизайн элегантен. Как вы достигнете этих 2, зависит от вас. Черт возьми, вы могли бы также использовать GOTO, если вы все еще можете доставлять элегантный код.

Answer 4

Я читал, что статические методы ... злые, когда вы пытаетесь реализовать модульное тестирование

Я никогда этого не читал. Не могли бы вы предоставить ссылку? И я бы оспорил это. Я использую и тестирую статические методы (функции) постоянно и без проблем.

---

Отредактированный

Спасибо за ссылку на Статические методы - Смерть тестируемости : Эта статья - мусор.

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

Это указывает на то, что автор не знает много о модульном тестировании. Конечно, вы можете тестировать процедурный код модуля.

Во время создания экземпляра я связываю зависимости с помощью mocks / friendlies, которые заменяют реальные зависимости.

Это ключевая ошибка: идея о том, что модульное тестирование требует фиктивных объектов. Это не. В любом случае вы можете передать фиктивные объекты в качестве аргументов тестируемому статическому методу: внедрение зависимостей не требует конструктора. Для получения дополнительной информации см. принятый ответ на вопрос «Статические методы: когда и когда нет»

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

Верно, но не имеет значения. Если статический метод A вызывает статический метод B , то это подробности реализации метода A . Таким образом, у вас нет никакого дела , пытающегося перехватить вызов на B . Просто обработайте A как единое целое.

Предположим, в вашем приложении есть только статические методы

Спор соломенного чучела. Очевидно, что в контексте современного модульного тестирования мы говорим о ОО-программе только с некоторыми статическими методами.