In most of my applications, I have a singleton or static "config" object, in charge of reading various settings from disk. Almost all classes use it, for various purposes. Essentially it's just a hash table of name/value pairs. It's read-only, so I haven't been too concerned with the fact that I have so much global state. But now that I'm getting started with unit testing, it's starting to become an issue.
One problem is that you don't usually want to test with the same configuration that you run with. There are a couple of solutions to this:
- Give the config object a setter that's ONLY used for testing, so you can pass in different settings.
- Continue using a single config object, but change it from a singleton to an instance that you pass around everywhere it's needed. Then you can construct it once in your application, and once in your tests, with different settings.
But either way, you're still left with a second problem: almost any class can use the config object. So in a test, you need to set up the configuration for the class being tested, but also ALL of its dependencies. This can make your testing code ugly.
I'm starting to come to the conclusion that this kind of config object is a bad idea. What do you think? What are some alternatives? And how do you start refactoring an application that uses configuration everywhere?