Because each unit test should be independent from the other.
To add to these points:Here is an excellent list of why making things global can be bad.
As I mentioned previously, if one part of your code changes part of your Singleton, this change will cascade down to everything else that uses that part, which could leave you in serious troubles if that behaviour is not intended.
Testing with a Singleton will be a little trickier, because you can only ever refer to that instance.
Instead of creating a new object and testing with that object, you might find yourself needing to reset your Singleton from one test to another, which certainly increases your workload and makes for more complex tests.
You might need to implement setUp and tearDown methods you otherwise might not need.
Ultimately, Singletons can be difficult to work with, because they hide information from you as they will hold data that is not explicitly declared anywhere else.
Not only will you need to trace it right back to the Singleton, instead of having a more local context, you might also discover that the data does not behave as you expected it to in every situation it is used.
Why are they good?A Singleton will help you hold data in a single place, with no risk that the data could be split between several instances of a class, or be different from instance to instance.
If you have some information that does not need to change, but needs to be accessed in different places, a Singleton could help you.
This does not seem like much, but it can be a powerful pattern used in the right context.
Why do I use one?Yeah, I’ll own up to it, I have a Singleton in my codebase.
I have a Configuration Singleton in my HTTP server, where I store a port and a directory.
When a user starts a server, they can either choose to use the default port and directory configuration that the Singleton is instantiated with, or they can choose their own configuration, that will replace the default configuration.
I made the decision to use a Singleton, because the Configuration is set when the server starts, and is never modified anywhere else in my codebase afterwards.
However, I needed to find a way to store the directory reliably so that I could access it in multiple places and know that it would never change once set.
This allows me to give my user the flexibility to choose the starting directory they want to explore, as well as generate relative and absolute paths according to that information.
One of the most frequent operations I do in my codebase is to look up and generate a path:String contentRootPath = Configuration.
getInstance().
getContentRootPath();String filePath = contentRootPath + request.
getPath();Not having to constantly determine what the root path is has made it much easier to focus on code that mattered.
It takes out the guesswork and keeps my path generating simpler, leaner and clearer.
If you are unsure whether a Singleton is the right choice, try to come up with a solution that does not involve one at first.
If you can do that relatively easily, don’t use one.
If you can’t, pick someone else’s brains to check if they can think of a solution, and if that also fails, just go for it, you can always rewrite code after all!Resources:How to Refactor Many Singletons — Stack OverflowHow should I refactor my code to remove unnecessary singletons? — Stack OverflowSingleton Pattern — Refactoring GuruSo Singletons are bad, then what? — StackOverflow.. More details