Test::DBIx::Class
Today, I tried to test a freshly created DB schema using Test::DBIx::Class
. Scanning through the documentation was impossible -- it knows far too many options to get captured within a few minutes. But carefully reading the brilliant manual is worth the time spent. Test::DBIx::Class
has a lot of options and test-functions tailored especially to the needs of DB-testing.
My primitive schema knows 3 tables: Sensors, Measures and AlarmConditions. Inside my t/
directory, I needed to create only one supplementary file to allow the tests to get coded: a config file t/etc/schema.pl
{
schema_class => 'Statistics::EasySchema',
force_drop_table => 1,
resultsets => [ qw(AlarmCondition Measure Sensor) ],
connect_info => ['DBI:Pg:dbname=statistics_test', 'user', 'secret'],
}
My tests started using a blank database which was OK for me in this particular situation with a primitive database like this.
My test-script partially looked like that:
use strict;
use warnings;
use Test::More;
use Test::DBIx::Class;
# ensure DB is empty
is Sensor->count, 0, 'no records in sensor table';
# add a sensor
ok my $sensor = Sensor->find_or_create({name => 'erlangen/keller/temperatur'}),
'find or create sensor';
is_result $sensor;
is_fields [qw(sensor_id name)], $sensor, [1, 'erlangen/keller/temperatur'],
'sensor fields look good';
is Sensor->count, 1, '1 record in sensor table';
# more test...
done_testing;
How easy things can be by simply using the right module :-)
Dear Wolfgang,
I'm glad the module helped you out and I am also happy to see a sweet, shortened version of the copious documentation. Actually, I have been long thinking of busting this module into several parts since after I published the first version I realized it was a bit more complicated to use that I had originally hoped. So I wrote as many docs as I could :)
Eventually I do see some bits as stand alone modules, such as the auto-creation of the database and so forth. I've actually used that myself sometimes when building an application from scratch, deploying a clean version of the db and fixtures at each startup until I get a version of the db that is good enough to settle down the schema a bit.
Thanks again for the write up!
jjnapiork
Today I received Gabor Szabo's perl weekly. Gabor interpreted my words above as a complaint for too much documentation. I am so sorry if my first phrase above leaves this impression. A module offering lots of things might need a long documentation which is the case here. I do not have a problem with verbose manuals if the amount of text is necessary in order to get things explained.
Oh holy lord of misunderstandings :)
I liked your post. Sorry if my words did not show that.