Test::DBIx::Class and create_ddl_dir

I just realised there is an odd ‘feature’ that comes into effect if you happen to combine Test::DBIx::Class and create_ddl_dir. It’s not technically a bug because it’s technically legitimate features but it causes some odd side effects in my test code.  Warnings about drop statements when no table existed.

$ /opt/perl5/bin/prove -l t
t/02-xmlcheck.t .... DBIx::Class::Storage::DBI::__ANON__(): DBIx::Class::Schema::deploy(): DBI Exception: DBD::SQLite::db do failed: no such table: phonenumbers [for Statement "
-- Table: phonenumbers
DROP TABLE phonenumbers"] at /opt/perl5.10.1/lib/site_perl/5.10.1/Test/DBIx/Class/SchemaManager.pm line 169
(running "
-- Table: phonenumbers
DROP TABLE phonenumbers") at /opt/perl5.10.1/lib/site_perl/5.10.1/Try/Tiny.pm line 98
t/02-xmlcheck.t .... ok
All tests successful.

I’ve been using Test::DBIx::Class to test my model code and by default it creates an SQLite database in memory so a drop statement at the start didn’t make sense. The actual error messages didn’t actually cause my tests to fail but they weren’t desirable. It turns out that the reason I was getting them was because I’d also done a create_ddl_dir to create schema files for databases, including SQLite and left the files in the dir I was running the tests from. The DBIx::Class code was detecting them and using them to generate the tables. They contained drop statements because they were standard schema’s intended for use with real databases.

As soon as I realised that and moved the schema files into a different directory the drop errors disappeared. As I say, I don’t think this is a bug, more a couple of features interacting in a way that wasn’t what I wanted. I’m just documenting what I found so that when I encounter it again in a couple of months and have forgotten the reason I’ll be able to read why.

Test::DBIx::Class is a really useful module and it makes doing tests of the data layer really simple. It’s worth checking out if you are using DBIx::Class because it makes the cost of doing data tests a lot lower. It’s possible to switch to using a real db if necessary but by default I use the in memory tests most of the time because it means there is no reason not to run the data tests wherever I deploy modules to.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s