Различные экземпляры Singleton с тестами JUnit
У меня есть автономный одиночный элемент, который успешно проходит тест. Но с группой тестов это перестало работать, с тех пор, как только одиночный элемент определяется, он не позволяет сбрасывать экземпляр.
Какие-либо идеи о том, как пойти об этом?
6 ответов
Не используйте синглтон.
В частности, единственное различие между синглтоном и глобальной переменной состоит в том, что синглтон пытается применить единственный экземпляр (например, делая конструктор закрытым).
Вместо этого сделайте конструктор общедоступным и напишите тесты, используя новые экземпляры.В вашей реальной программе используйте getInstance () , чтобы получить канонический глобальный экземпляр (или используйте контейнер IOC).
И помните, что одиночки - патологические лжецы .
Если вам все еще слишком нравится идея синглтона, вместо того, чтобы делать конструктор общедоступным, вы можете добавить общедоступный (и статический) фабричный метод для создания экземпляров таким образом, чтобы его нельзя было использовать случайно, например :
public static MyClass TEST_CreateInstance() {
return new MyClass();
}
Я предполагаю, что у вас есть частное статическое поле в вашем классе Singleton для хранения инициализированного экземпляра.
Если вы не хотите изменять свой код, вы можете определить метод Skydown, который запускается после каждого теста, и в этом методе вы устанавливаете это статическое поле в NULL через отражение, как видно здесь .
Я предполагаю, что у вас есть частное статическое поле в классе Singleton для хранения инициализированного экземпляра.
Если вы не хотите изменять свой код, вы можете определить метод Shopdown, который проходит после каждого теста, и в этом методе вы устанавливаете это статическое поле на NULL через отражение, как видно здесь .
-121--1620319-Как правило, остерегайтесь синглтонов, чаще всего они являются злыми, плохими дизайна и имеют тенденцию представлять большие глобальные переменные Yucky (что плохое для обслуживания).
Все еще, чтобы получить тесты на месте, вы можете сделать:
static setInstance(...){ //package visibility or in difficult cases you have to use public
instance = ...;
}
Как сказано, что это больше обходной путь. Так что получите первые тесты, но затем рефакторируйте от шаблона Singleton.
Вы можете добавить метод уничтожения Singleton, например Enversme (); Где вы деинициализируете все и установили экземпляр Singleton в NULL.
public void destroyMe(){
this.instance = null;
//-- other stuff to turn it off.
}
Я оставлю проблем с синхронизацией;)
Но зачем вам нужно повторно инициализировать свой Singleton для каждого теста? Это не должно отличаться на основе концепции синглтона.
Я предлагаю вам попытаться увеличить размер нового поколения, например, -xx: Newsize = 96m XX: newratio = 3 . Используйте JVISULVM (включенные в JDK), с плагином Visual GC , чтобы посмотреть, как используются молодые и старые пробелы.
Экземпляр Singleton должен быть передан в SUT, тестируемый самим - таким образом вы создаете Singleton (и уничтожить) для каждого теста. Принимая структуру МОК и насмешек, таких как Mockito, сделает этот подход почти тривиальным.
Я настоятельно рекомендую отказаться от синглтонов в качестве шаблона проектирования и использовать синглтоны в качестве области действия (внедрение зависимостей). Это просто решит вашу проблему.
Но, предположив, что вы застряли в мире синглтонов, у вас есть несколько вариантов в зависимости от того, тестируете ли вы синглтон или зависимость.
Если вы тестируете зависимый элемент, вы можете имитировать Singleton, используя PowerMock и JMockIt . См. Мой предыдущий пост о имитации Runtime.getRuntime для получения инструкций о том, как это сделать.
Если вы тестируете синглтон, вам нужно ослабить правила построения или дать синглтону метод «сброса».