Реализация защищенного конструктора без параметров для модульного тестирования

Question

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

Альтернативой является извлечение интерфейса, но это не всегда желательно в кодовой базе, над которой у вас нет полного контроля ...

Answer 1

Это не идеально, но это действительно.

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

И в Эффективная работа с устаревшим кодом Майкл Фезерс обсуждает несколько таких приемов, отмечая, что создание защищенных для тестирования вещей может быть лучше, чем публичное, хотя это не обязательно лучший способ сделать что-то. , (На самом деле, я бы порекомендовал вам прочитать эту книгу, если вы работаете с устаревшим кодом, который звучит так, как вы).

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

Answer 2

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

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

Answer 3

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

Изменение вашего кода или API для облегчения модульного тестирования, как правило, нежелательно (см. Обсуждение «Должен ли я выполнять модульное тестирование частных методов»), поэтому на самом деле использованиеновый класс, вместо того, чтобы модифицировать существующий, может стать шагом вперед.

Answer 4

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

Это дает возможность для подклассов создавать экземпляры класса по-своему, без необходимости предоставления параметров базовому конструктору.

Моделирование фреймворков - это как раз такой пример подкласса, который хочет, чтобы свобода могла создавать экземпляр класса по-своему; фиктивный объект не заботится о настройке свойств по умолчанию или зависимостей, так как он все равно будет имитировать возвращаемые значения.

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

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