in reply to Packaging and testing a module which requires a database

I've used DBD::AnyData with a very small database (ten rows per table) to test against data I could update, delete, and reload as necessary. It worked well, despite there being some SQL differences. They should be fixed now.

I've also used an environment variable to skip slow or tricky tests. TEST_DATABASE or the like would work. You'd run it with a command such as:

TEST_DATABASE=1 make test

Replies are listed 'Best First'.
Re: Re: Packaging and testing a module which requires a database
by legLess (Hermit) on Feb 06, 2004 at 17:57 UTC
    I hadn't thought of an environmental variable; that sounds like the best way. Thanks!

    My only problem with AnyData (or SQLite, or anything else) is that I depend on a MySQL-specific function for autoincrementing primary keys. I just don't want to spend the mental energy hacking around that until I've done more work on features that people are asking for.

    But that's probably false laziness. I haven't done a realistic time assessment and I need to.

    In the "small world" department, Jeff Zucker was just yesterday bemoaning the fact that he hasn't had time to implement autoincrement keys in AnyData.
[reply]

In Section Seekers of Perl Wisdom