It's hard to test code that uses singletons. Typically, the code you want to test is coupled strongly with the singleton instance. You can't control the creation of the singleton object because often it is created in a static initializer or static method. As a result, you also can't mock out the behavior of that Singleton instance.
If changing the implementation of a singleton class is not an option, but changing the client of a singleton is, a simple refactoring can make it easier to test. Let's say you had a method that uses a Server as a singleton instance:
public class Client {
public int process(Params params) {
Server server = Server.getInstance();
Data data = server.retrieveData(params);
...
}
}
You can refactor Client to use Dependency Injection and avoid its use of the singleton pattern altogether. You have not lost any functionality, and have also not lost the requirement that only a singleton instance of Server must exist. The only difference is that instead of getting the Server instance from the static getInstance method, Client receives it in its constructor. You have made the class easier to test!
public class Client {
private final Server server;
public Client(Server server) {
this.server = server;
}
public int process(Params params){
Data data = this.server.retrieveData(params);
...
}
}
When testing, you can create a mock Server with whatever expected behavior you need and pass it into the Client under test:
public void testProcess() {
Server mockServer = createMock(Server.class);
Client c = new Client(mockServer);
assertEquals(5, c.process(params));
}
Remember to download this episode of Testing on the Toilet and post it in your office. Permalink | Links to this post |
7 comments:
This doesn't cover a few downfalls to the approach.
It requires the users of the client know about where to get the singleton and it forces them to access it for every creation of the client class.
Another problem is that the singleton that this ignores the difference in when the singleton is acquired, which could have important implications that need to be addressed.
It should be included in such a suggestion that the client class take the singleton injection as an optional parameter, and access the singleton by default, possibly and specifically on each use of the singleton.
After several failures, we (I and my team in the undisclosed company I work for) got to couple of conclusions:
1. DI frameworks (e.g. Spring) are extremely friendly for testing.
2. If you can't use a DI framework, create (a simple) one.
Now (2) requires some explanation – what we do is have one real singleton – The singleton (application context, container, god – take your pick) which acts as a very restricted access map to several contexts "hubs". Each hubs converse directly with the map, first loading it with the required objects, then extracting and typecasting as needed. Context objects have a very small footprint on construction and are only initialized on event (application init) / request (same as real singletons)
Testing is facilitated in either of two ways:
1. If you only need a small number of mock contexts, you create them and load them manually into the singleton map. Future requests will retrieve them. On tests teardown, you empty the entire map.
2. If you need a large number of mock contexts (big unit tests / integration tests), you just fire one (or more) of the real hubs and overwrite only what's needed in the map (if anything is) with mock implementations.
This approach has the merit of being very easy on production code and yet (almost) as testable as real DI.
To be honest, I do not see the advantage...
With the first implementation of the Client-Class, it would have been possible to do:
Client c = new Client();
client.process();
That's all... what's the drawback here?
It's hard to test code that uses singletons. << understatement of the year :P
We have had alot of luck using DI for testing, and when singletons are necessary provide an alternative getInstance method which takes in the parameters to construct the object with for testing.
For this thing I use Guice.
網頁設計,情趣用品店,情趣用品專賣網
A片,色情A片,免費A片,成人影片,色情影片,a片免費看,情色貼圖,情色文學,情色小說,色情小說
AV,AV女優
辣妹視訊,美女視訊,視訊交友網,視訊聊天室,視訊交友,視訊美女,免費視訊,免費視訊聊天,視訊交友90739,免費視訊聊天室,成人聊天室,視訊聊天,視訊交友aooyy
哈啦聊天室,辣妺視訊,A片,色情A片,視訊,080視訊聊天室,視訊美女34c,視訊情人高雄網,視訊交友高雄網,0204貼圖區,sex520免費影片,情色貼圖,視訊ukiss
希望大家都會非常非常幸福~
「朵朵小語‧優美的眷戀在這個世界上,最重要的一件事,就是好好愛自己。好好愛自己,你的眼睛才能看見天空的美麗,耳朵才能聽見山水的清音。好好愛自己,你才能體會所有美好的東西,所有的文字與音符才能像清泉一樣注入你的心靈。好好愛自己,你才有愛人的能力,也才有讓別人愛上你的魅力。而愛自己的第一步,就是切斷讓自己覺得黏膩的過去,以無沾無滯的輕快心情,大步走向前去。愛自己的第二步,則是隨時保持孩子般的好奇,願意接受未知的指引;也隨時可以拋卻不再需要的行囊,一路雲淡風輕。親愛的,你是天地之間獨一無二的旅人,在陽光與月光的交替之中瀟灑獨行.............................................................................................................有時,你覺得痛。胃痛的時候,接受它,承認這個疼痛是你的身體的一部份,與它和平共處。心痛的時候,接受它,承認這個經驗是你的生命的一部份,與它和平共處。抗拒痛的存在,只會讓它更要證明它的存在,於是你就更痛。所以,.無論你有多麼不喜歡痛的感覺,還是要接納這個痛的事實。與你的痛站在同一邊,不逃避,不閃躲,不再與你的痛爭執,如此,你的痛才會漸漸不再胡鬧,才會乖乖平息下去。.................心願-你許下了一個心願,你閉上眼睛,在冥想之中把這個心願交託宙給宇整個讓宇宙推動它全部的力.量去執行.,你看見星球與星球的引力牽繫著彼此,你聽見虛空與虛空.唱裡著和妙美的聲音,為了你的心願,整個宇宙正在相互傳遞,然後你放下了心願,不僅是放下,最好你還把你的心願忘記,唯有如此,它才能脫離你,發展它自己,
當它在宇宙的遊歷結束之後,它自然會來到你身邊,以你曾經希望的方式回應你,許下,只是讓它發生,放下,才是讓>它實現,你的心願使你懂得不能執著的奧秘...................
Post a Comment