We have a global dictionary of application settings (read from a DB on start-up and refreshed when required) and a static class with a bunch of methods to get these settings. This is historic, but I see no reason why it would be done differently today unless it adds value in testing...The options for swapping out values for testing different scenarios I think include:Updating the database values before the testMock the static methods and intercept the ones you need and allow defaults for the ones that don't impact the testRefactor code to take in a settings instance (e.g. IDepartmentApiSettings) at construction time (constructor injection) and use this instead of the static methodsThe first two work without code change, so are preferred on the legacy code. The third therefore would only be viable for new code (or code that can be easily refactored).Now here's my question, is there any real advantage to injecting the settings in this way? Or would you live with static methods and use option 1 or 2 to keep consistency across the code base?Note: Code is C# but that shouldn't make any difference, would be the same question for Java, so I won't tag it.
Global / Application settings and testing
unit testing;integration tests