I haven't used this module myself, but perhaps create two test suites: "make test" tests everything you can test without burdensome external dependencies, and "make testsql" either depends specifically SQLite2 or using a user-provided DSN. The users who want to put more effort into testing can invoke the latter. I'm not sure if this is an appropriate solution for "smoke testing", though.
Ted Behling -----Original Message----- From: Tyler MacDonald [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 9:43 PM To: dbi-users@perl.org Subject: extra dependancies vs. testability? DBIx::Transaction currently only depends on DBI, but for it's unit tests to run you need a DBI driver available. If SQLite2 is available, it gives you a nice default DSN to test DBIx::Transaction in a completely self-contained environment. The problem I'm facing is that smoke testers (notably CPAN testers and ppm.activestate.com) can't automatically test this module properly because the test dependancy on having some sort of DSN isn't made obvious to them. I'm in a bit of a dilemma here. I'd like my package to be automatically testable against some sort of "real" DBD driver, but I don't neccessarily want every person who installs my module to be obliged to install DBD::SQLite2 alongside it. As nice of a module as it is, it seems like bloat if they're never going to use it for anything else. What do you think I should do about this? Bite the bullet and depend on SQLite2? Create an overly complex mock object that doesn't emulate any "real" DBD driver's behaviour? Or is there another, better solution? Thanks, Tyler
