I want to test DB operations etc, i.e. create some entries, update, delete them, etc. Now, my problem is that all this testing interfers with the 'real' data if I run the tests against the 'real' database.

There are as many ways of skinning that cat as there are folks trying to skin it. Here are some of the aproaches I've seen without passing judgement on any of them.

Environmental values

As you pointed out you an always use your environmental values to drive your application's behavior. You showed one way, but here's an alternative:

# .bashrc sniglet

export DBHOST="mytestdbhost.mydomain.tld" 
export DBDB="mytestdb"
export DBUSER="user"
export DBPASSWORD="SeCrEt"
export DBDRIVER="mysql"

------- 8<snip! 8<--------------------------

# in some perl code, far far away
use DBI;
my $dbhost = $ENV{'DBHOST'};
my $dbname = $ENV{'DBDB'};
my $dbuser = $ENV{'DBUSER'};
my $dbpassword = $ENV{'DBPASSWORD'};
my $dbdriver = $ENV{'DBDRIVER'};

my $DSN=sprintf("DBI:%s:host=%s:database=%s",
                $dbdriver,$dbhost,$dbnaem);
my $dbh=DBI->connect($DSN,$dbuser,$dbpassword)
    or die DBI->errstr;

... etc....
[download]

The above ripped from some code I'm maintaining. The actual values changed to protect the guilty.

Configuration Files

There are two general methods I've seen for doing this. One uses an external configuration file that you either parse yourself or you can use one of several AppConfig family of CPAN modules to do your dirty work.

The other method I've seen (and used myself) is to create your own module that encapsulates your database access configuration. The one I use over and over again I call (oddly enough) DbConfig.

use DBConfig;
use DBI;

my $dbh=DBI->connect(DBConfig::DSH,DBConfig::User,DBConfig::Password) 
+or die $DBI::errstr;
[download]

When I install DBConfig on my production boxes I make the appropriate changes to the module. Otherwise the code is identical.

As always in Perl TIMTOWTDI!