Как я могу протестировать Singleton-класс с DUnit?
Хорошо, я нашел это, но это - Java не C#:
http://timeandmoney.domainlanguage.com/
5 ответов
Несколько дней назад ответили на аналогичный вопрос здесь, высмеивая синглтон . Исходный пост предназначен для C # .Net в отношении имитации поведения синглтона, но все же должен применяться.
Что касается шаблона синглтона, в нем нет ничего плохого - во многих случаях мы хотим централизовать логику и данные . Однако между синглтоном и статическим классом существует очень большая разница. Создание вашего синглтона в виде жесткого кода статического класса, который реализуется для каждого потребителя в вашем приложении, что делает модульное тестирование очень сложным!
Что вы хотите сделать, так это определить интерфейс для вашего синглтона, раскрытие методов для использования вашими потребителями. Ваши потребители, в свою очередь, передают ссылку на реализующий класс тем, кто их создает [обычно это ваше приложение или контейнер, если вы знакомы с Dependency Injection \ Inversion of Control].
framework, который создает экземпляры потребителей, который отвечает за обеспечение того, чтобы один и только один экземпляр перемещался вокруг. На самом деле это не такой уж большой переход от статического класса к ссылке на интерфейс [как показано в ссылке выше], вы просто теряете удобство глобально доступного экземпляра - я знаю, что знаю, глобальные ссылки ужасно соблазнительны, но Люк повернулся спиной к Темная сторона, вы тоже можете!
В общем, лучшие практики рекомендуют избегать статических ссылок и поощряют программирование против интерфейсов. Помните, что с этими ограничениями все еще можно применить шаблон singleton. Следуйте этим рекомендациям, и у вас не должно возникнуть проблем с модульным тестированием вашей работы :)
Надеюсь, это поможет!
singleton! = Общедоступный статический класс , а не singleton == single instance
Я использую следующий шаблон , когда пишу статические синглтоны, которые я могу имитировать. Код - Java, но я думаю, вы уловите идею. Основная проблема с этим подходом заключается в том, что вам нужно ослабить конструктор до package-protected (что вроде как побеждает настоящий синглтон). В качестве примечания - код применяется к возможности имитировать ваш "статический" код, не обязательно просто вызывая его
Отсутствие тестируемости - одно из основных недостатков классической модели Singleton (метод статического класса, возвращающий экземпляр). Насколько я понимаю, этого оправдания достаточно, чтобы перепроектировать любой код, использующий синглтоны, для использования какого-либо другого дизайна.
Если вам абсолютно необходимо иметь единственный экземпляр, то внедрение зависимостей и запись в интерфейс, как предлагает Джонни Г., определенно лучший вариант.
Если вам необходимо использовать синглтон (и для этого есть причины ... но я всегда стараюсь избегать этого, если это возможно). Я бы рекомендовал использовать контейнер IOC для управления им. Я не уверен, есть ли он для Delphi или нет. Но в Java вы можете использовать Spring, в .NET вы можете использовать Windsor / Castle. Контейнер IOC может удерживать Singleton и может регистрировать различные реализации для тестирования.
Вероятно, это слишком большая тема, чтобы углубляться в этот фрагмент.
Обычно я использую синглтоны только для объектов-легковесов или объектов с аналогичными значениями. Изучение контейнера IoC (как обсуждалось выше), вероятно, является лучшим способом обработки разделяемого объекта, чем синглтон.
Учтите, что в Smalltalk (откуда возникло множество этих шаблонов), true и false были по сути синглетонами :)