There is no "true and unique" way to do it, it all depends on so many different factors.

Personally, I am in favour of using an external configuration file (I really like YAML) in case there is some configuring to be done and this configuration changes from time to time or place to place. Also it is less "risky" to give users access to the configuration file rather than allowing them to edit the module or script directly.

++CountZero

I am second to you, we always keep database configuration in YAML file. So whenever the program starts it read the database configurations from yaml file and process the test cases.

It will be useful if you keep database configuration in YAML, the code can be shared with other so that they can easily change only the yaml file, instead of finding them in .pm file

---

All is well. I learn by answering your questions...

I would also recommend you consider augmenting this system with one or more of these additional features:

1. A default configuration file;
2. Added: A database-resident collection of configuration settings; this would necessitate database connection information be in one of the other mechanisms on this list;
3. Environment variables which override the default config file;
4. A command line switch to specify an alternate configuration file, which overrides environment variables and default configuration file entries;
5. Other command line switches which override any other settings.

As a rule, code and data should be separate; configuration information is data. Of the two choices you've given, I'd go with a .inifile.

but its huge database, as an automation suit who will configure such big data.... only the one database field which user should know.. rest no need.. Also How can we communicate to the database in .ini files.. database is remote system.

Yes, that is a modern additional feature to consider: Store configuration in a database (could even be user-specific!); you could reduce the .inifile to holding the database connection information.

But I wouldn't hard-code anything in the .pmwithout a very specific and strong argument to do so.

The benefits of keeping code and data separate is a very, very long list, and I've probably forgotten more reasons that some people will learn. Don't make your people edit .pmfiles just to make a config change. You are likely to live to regret it if you do.  :-)

Side note (and I really am just trying to be helpful, not demeaning in any way): A suit (sort of rhymes with "soot") is something you wear, or one of a family of cards in a deck of cards. I guess it can also be a legal action designed to seek compensation for perceived wrongs.

A suite (rhymes with "sweet") is a group of things tied together; a suite at a hotel is comprised of adjoining rooms, and a test suite is a bunch of tests that are grouped together as a (generally functional) block.

IMHO You should use config files, but your test suite shouldn't be updating the config files; instead each test should have it's own config file which gets changed by a Human when that test requires a configuration change.

Also, IMNSHO this time, YAML is dead, it's all JSON in the 21st century :)

Hi Bhusan,

Nice to see you are making progress.

As others have said, keep your config information out of the program code.

I often use what marinersk suggested, which is ENV variables. Each user can set the database config info as ENV variables and the program checks for these and either proceeds or throws an error. I usually set them in each user's .bashrc

Using an .ini file is also fine, although you might name it something like .ourapprc to follow convention if you are on a *nix/OSX system. Again each user keeps a copy of the file in his home directory, and the program reads in the data at startup.

You can combine one of these per-user solutions with a default conf file that holds data that will not change per user, e.g. the DB name and so on.

Main thing is to keep it all very simple!. Use a CPAN module to read your conf information, and maybe to write it.

Yes, JSON is the new standard format for static data, but if all you need is to store the user's DB username, password and maybe a couple of other things, use something simpler. I like Config::Tiny as it is VERY simple, pure Perl and the file format is familiar to almost everyone.

In the modules/multi-module applications I write, I create separate config files in the t/ directory that are configured for specific tests.

In my module/program files, I load the configs something like this:

    my $conf_file;

    if ( exists $ENV{'CONFIG'} ) {
        $conf_file = $ENV{'CONFIG'};
    }
    elsif ( exists $params->{config} ){
        $config_file = $params->{config};
    }
    else {
        $conf_file = '/usr/local/etc/program.conf'; 
    }
[download]

Then, near the top of each test file for example...

my $conf = abs_path( 't/conf/this_test.conf-dist' );
$ENV{'CONFIG'} = $conf;
[download]

In that way, each test script can have its own config file that is predetermined, and consistent. If you're not testing against a config itself, I don't see it wise to modify it on the fly during testing. I prefer to have static data so my tests are reliable.

-stevieb

Modify the .ini file?   N-O.

Specify the name of an alternative ini file that is to be used for test purposes?   Perhaps.

Write a .pm module containing configuration information, with conditional logic therein?   Or, an outer, “wrapper” module which uses UNIVERSAL::require to choose from one of several?   Maybe better-yet.

A test might well use a different or modified environment/configuration, but it must not in any way alter the configuration, if only because those alterations would have to be tested too, ad infinitum.