views:

54

answers:

2

Well, the question speaks for itself. I use to have a static Config class in my project that lazy-load the data from the config file like this :

    private static string _foo;
    public static string Foo
    {
        get
        {
            if (string.IsNullOrEmpty(_foo))
                _foo = ConfigurationManager.AppSettings["foo"];
            return _foo;
        }
        set
        {
            _foo = value;
        }
    }

That way in my tests I can just set up the Config class the way I want and it won't need to access the filesystem. I also parse to specific types, or to Enums for example.

Do you use a better approach? please share!

+1  A: 

I am used to the Settings : System.Configuration.ApplicationSettingsBase.

  1. It supports strong typing and
  2. is already encapsulated so you don't need to worry, just access the values
  3. and it is also integrated with the IDE.
  4. and it supports both Application and User settings
  5. You can use custom settings for the test project

For more info please look at http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

Jader Dias
I just got to try it now, and it is very nice. But I find an annoying behavior here. I have those settings in a library, and I use that library from another console app. Without adding the necessary settings to the console app, the library picks up the values from the setting file. I'd rather have the app crashing than using default values that I don't expect!
Stephane
@serbrech It's a common practice to avoid user settings in libraries. IIS for instance doesn't even allow it in some cases. If you really really cannot pass your settings as parameters to your library, then you will have to copy it to the app.config of your application.
Jader Dias
I used it and it is a better choice, still not completely convinced though. But the problem I mentionned with the default settings being used still seems weird to me. It is a common problem with Linq to Sql users for example. If you tick the check box to embed the settings and change/remove the connection string from the config file, you might have surprises when running your tests against the Production DB!
Stephane
A: 

What makes you think you need to use lazy loading? Are you assuming there would be a performance problem if you accessed the config each time? Try it and find out? You may find that it's fast enough. You may even find that the data are cached internally.

John Saunders
the purpose of lazy loading here was to be able to set it to what i want in a test. why would that be a problem? And you don't answer my question either... How do you do that?
Stephane
You should update your question to indicate that the only reason for lazy-loading is for unit tests. It's not clear. BTW, the answer is that I don't wrap config files - I use different config files when necessary for tests.
John Saunders
how do you write tests for different configuration then? you can have only 1 config file in your test project too...
Stephane
config files are just XML files. If I ever need to test different configurations, I copy in the different config file. BTW, for _unit_ tests, I don't think I've ever needed multiple configurations. Maybe for functional tests.
John Saunders
In the above, I meant, "if I ever have to test different configuration _files_". I'm always testing different configuration _values_ - by having the test set the configuration variable directly. In your example, the test would set `object.Foo` before running the body of the test.
John Saunders