Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

I have heard and read quite a bit on problem involved while testing when singleton is involved.

Here are 2 common ways to create a singleton in Objective-C:

+ (instancetype)sharedInstance
    static dispatch_once_t once;
    static id sharedInstance;
    dispatch_once(&once, ^
        sharedInstance = [[self alloc] init];
    return sharedInstance;


+(instancetype *)singleObj
    static myClass *single = nil;

            single = [[myClass alloc] init];
    return single;

From reading I learnt that singleton is bad for that it represents "global state". It conceals its identity from you, especially when it is present when you have no idea that it is. It obfuscates clarity when it was not you who created it and you are a new guy who just began working on the project in which a single ton (or more) is (are) involved.

Another thing I learnt is that there are rare cases that a single can be "spawned" more than once, although I have no idea under which sort of circumstance it would be (I would really appreciate it if some of the experts, who know how this could happen, would explain me this.

So, my question here is:

Is it really true that singleton is bad in terms of testing aspect? If so, how bad it is exactly?

If you were a seasoned tester that happened to come across the issue regarding singleton as mentioned above, how would you come about tackling with the issue?

How would you suggest /convince the developer, who created this, not to do this?

What would be a better alternative as far as testing and development is concerned? Is there an area where the best of both worlds can benefit from not having singleton?

share|improve this question

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.