On Thu, 12 Jan 2006 09:56:55 +1000, Robert Loomans wrote:
Hi Robert
> As a compromise, Tyler, how 'bout you only run the tests in this
> case if SQLite is *already* installed? Other modules already do
> things this way. eg, look at Log::Log4perl and the tests for LWP,
Yeah, this should be ok.
--
> > - If DBI_DSN is not set, default to depending on, and testing
> > against, SQLite.
>
> No. People should have to explicitly set DBI_DSN to make it do something.
> So, unset should be the same as set to empty string.
I don't agree.
As a compromise, Tyler, how 'bout you only run the tests in t
On Wed, 11 Jan 2006 13:45:30 -0800, Tyler MacDonald wrote:
Hi Tyler
I do understand your point, but I think you need to re-think this.
> *whines* But this would break the functionality I was looking for
> in the first place: good automated QA being in a somewhat self-
So far so good.
> contain
Ron Savage <[EMAIL PROTECTED]> wrote:
> > - If DBI_DSN is not set, default to depending on, and testing
> > against, SQLite.
> No. People should have to explicitly set DBI_DSN to make it do something.
> So, unset should be the same as set to empty string.
*whines* But this would break the
On Wed, 11 Jan 2006 13:07:18 -0800, Tyler MacDonald wrote:
Hi Tyler
> Currently, it *does* use the prompt() function supplied by
> ExtUtils::MakeMaker, which is supposed to prompt you if you have a
> controlling terminal, so long as PERL_MM_USE_DEFAULT is not set.
Excellent! Much appreciated.
-
On Wed, 11 Jan 2006 13:19:41 -0800, Tyler MacDonald wrote:
Hi Tyler
> I've had some time to digest this, and it seems that rather than
> coining an entirely new environment variable, I could use DBI_DSN:
Good!
Here are my votes:
> - If DBI_DSN is set, use that as the DSN for testing, and don't
Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> > If you really want, make the SQLite tests optional if some environment
> > variable is set (eg, SKIP_SQLLITE_TEST).
>
> OK, I like the environment variable thing. That gives me the
> opportunity to warn a user installing manually via CPAN that t
Ron Savage <[EMAIL PROTECTED]> wrote:
> On Tue, 10 Jan 2006 20:00:14 -0800, Tyler MacDonald wrote:
>
> Hi Tyler
>
> > OK, I like the environment variable thing. That gives me the
> > opportunity to warn a user installing manually via CPAN that they
> > don't have to install SQLite2 if they don't
On Tue, 10 Jan 2006 20:00:14 -0800, Tyler MacDonald wrote:
Hi Tyler
> OK, I like the environment variable thing. That gives me the
> opportunity to warn a user installing manually via CPAN that they
> don't have to install SQLite2 if they don't want.
Just for the record: When I install a set of
Robert Loomans <[EMAIL PROTECTED]> wrote:
> > That's what it does right now. The tests don't depend on SQLite2
> > per-se, just a DSN that points to a DBI driver that supports transactions
> > (eg; pretty much everything except MySQL ;-)
> Errr MySQL supports transactions just fine at least
At 7:26 PM -0800 1/10/06, Tyler MacDonald wrote:
Another option that occured to me while I was loading the dishwasher
was bundling SQLite2 (or something like it) in my t/ directory. Sure, it
will consume a bit of extra bandwidth when the package is downloaded, but it
won't leave the bloat
Ted Behling <[EMAIL PROTECTED]> wrote:
> Sorry for replying to my own e-mail, but I had another thought. What
> about just failing gracefully if SQLite2 isn't available? If it's
> installed, it gets used; if not, a warning is shown and the dependent
> tests are skipped.
That's what it do
y, January 10, 2006 10:12 PM
To: dbi-users@perl.org
Subject: RE: extra dependancies vs. testability?
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 testsq
e 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
Sub
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 teste
15 matches
Mail list logo
