[Pdx-pm] interesting testing hole thats been dug

Ovid publiustemp-pdxpm at yahoo.com
Wed Jan 3 03:08:36 PST 2007


--- Michael G Schwern <schwern at gmail.com> wrote:
> If you're putting testing code into production code something is
> wrong.  Your production code should not have any special cases for
> testing.

I used to think that and I find myself putting testing hooks all the
time.  Sure, I could do all sorts of things to intercept a 'print'
statement in a command-line tool I'm writing or I could just use:

  sub _print {...}

And override &_print rather than try to grab STDOUT.
 
> Finally, you can question why you're mocking the database connection
> at all.  As its not testing the real code, mocking should be a last
> resort.  (I presume by mocking you mean replacing the database
> methods with dummy calls that return dummy data).  Instead, consider
> having the tests create a new test database, load some test data in
> it and work from that.  SQLite is fantastic for this sort of thing.

I mostly agree with this.  In working with MySQL, I finally gave up
trying to use SQLite for this because certain coworkers are very fond
of using MySQL-specific SQL, thus guaranteeing non-portable code (damn
it).  Now I just dump the schema and load that directly into a dummy
test database.  With MySQL:

  mysqldump --no-data $database [$table|$tables] > schema.sql

Then if you have some static data in the database which you need for
your tests, dump the few tables which have that data and merge the
resulting SQL into schema.sql.  You can then import that into a clean
test database and your code is much easier to test.  Here's something I
have at the top of the SQL I import (obviously MySQL-specific and
processed via Template Toolkit):

  DROP DATABASE IF EXISTS `[% database %]`;
  CREATE DATABASE `[% database %]`;
  use `[% database %]`;

  ... rest of SQL statements ...

And then I load it when my tests start:

  mysql < schema.sql

This is an easy strategy to follow for just about and DBMS.  Plus, if
you set up your tests so every developer gets a different database
name, they can all use this strategy simultaneously without worrying
about collisions (and your tests run against the actual DBMS you're
using, rather than SQLite).

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/


More information about the Pdx-pm-list mailing list