This distribution has been tested as part of the cpan-testers
effort to test as many new uploads to CPAN as possible. See
http://testers.cpan.org/
Please cc any replies to [EMAIL PROTECTED] to keep other
test volunteers informed and to prevent any duplicate effort.
--
Dear Dan Collis Puro,
This is a computer-generated error report created automatically by
CPANPLUS, version 0.048. Testers personal comments may appear at
the end of this report.
Thank you for uploading your works to CPAN. However, it appears there
were some problems testing your distribution.
TEST RESULTS:
Below is the error stack during 'make test':
C:\Perl\bin\perl.exe "-Iblib\lib" "-Iblib\arch" test.pl
1..12
ok 1
ok 2
ok 3
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
DBD::mysql::db do failed: Table 'nested_set' already exists at
blib\lib/DBIx/Tree/NestedSet/MySQL.pm line 64.
DBD::mysql::db do failed: Table 'nested_set' already exists at
blib\lib/DBIx/Tree/NestedSet/MySQL.pm line 64.
NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' : return code '0xff'
Stop.
Additional comments:
A couple of questions:
1) Why are you trying to trash my database?
2) Why do you need to test whether DBI and the DBD drivers work?
In the first instance, there is no reason to try and access a live database.
Your users may not have direct access to the database they usually access
anyway. With automated testing, as in this case, the UI provides no detailed
information. In this instance the failure may simply because I have tested your
distribution previously, and because the tests failed, the database and tables
get left behind. However, cleaning these up is fraught with problems, as
although the table 'nested_set' may not be used, the 'test' database could be.
Should you delete the latter it could have untold destructive consequences. I
note in you 'test.pl' the following line:
$dbh->do('drop table nested_set');
while this is certainly an attempt to clean up, it is in no way fool-proof. In
this run, the test fails and the table remains. If you want to make a better
job of this, try:
END { $dbh->do('drop table nested_set'); }
In the second instance, the DBI and DBD drivers are fully tested within their
own distributions. There is no reason why you should be trying to test them
further.
In both instances there is no reason you should be accessing a database at all.
However, if you really feel you must, then can you provide a test for the
distribution that doesn't require a database and use this as the default. Using
DBD::Mock or Test::MockObject to fake the database, you can easily test the
distribution to correctly handle the data, rather than testing the database. If
the user wants to manually test the database of their choice, they can still do
so.
Sorry if this sounds a little harsh, but there are an increasing number of
modules that assume it's okay to access a default database during automated
testing.
Thanks,
Barbie.
--
Summary of my perl5 (revision 5 version 6 subversion 1) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cl', ccflags ='-nologo -O1 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE
-DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-DPERL_MSVCRT_READFIX',
optimize='-O1 -MD -Zi -DNDEBUG',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf
-libpath:"C:\Perl\lib\CORE" -machine:x86'
libpth="C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib" "C:\Program
Files\Microsoft Visual Studio\VC98\lib" "C:\Perl\lib\CORE"
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf
-libpath:"C:\Perl\lib\CORE" -machine:x86'
