Re: Tests needed for bugs 64330 and 66127

On 12/03/2011 10:55, Tim Bunce wrote:
> On Fri, Mar 11, 2011 at 10:27:16PM +0000, Martin J. Evans wrote:
>> On 11/03/2011 16:53, Tim Bunce wrote:
>>> Time's in very short supply at the moment, but if someone can contribute
>>> tests for these (ideally as patches to existing test scripts) then I'll
>>> fix'em as soon as I get a moment.
>>>
>>> Both are simple:
>>>      https://rt.cpan.org/Public/Bug/Display.html?id=66127
>>>      https://rt.cpan.org/Public/Bug/Display.html?id=64330
>>>
>>> Tim.
>> Attached a patch for ping issue. However:
>>
>> o wasn't sure where to put it 08keeperr.t seemed to have some logic
>> o it raised another issue - ping on DBD::Sponge does not return true
>> and DBD::Sponge does not have ping. I left the test in for that so
>> it produces 2 errors not 1.
>>
>> Of course by the time it is re-run with those z* tests the errors mount up.
>>
>> I'll commit it if you want but because of above I haven't.
> Yes, please do.
>
Done
>> If you give me a hint where the best place for the other bug is I'll
>> try and do that too.
> Umm. I hate to see the t/10examp.t getting any bigger (it really needs
> breaking up) but just after the "check ShowErrorStatement ParamValues
> are included and sorted" test seems like a good spot.
>
> Just call execute(1,2); # not enough args
> check that that returns an error
> and the errstr values don't contain ParamValues
> and that $sth->{ParamValues} is empty.
>
> Thanks!
>
> Tim.
I didn't do it quite like that mostly because errstr never contains 
ParamValues - only the PrintError and RaiseError msgs do. Attached patch 
p1 adds the test but you might want to look at the last test as it 
checks $sth->{ParamValues} is undef and until it is implemented I am 
unsure if you'll get an empty hashref or undef. This is committed. BTW, 
it needs Data::Dumper but I believe this is core and it is already used 
in other tests.

Also, attached is patch p2 which just gets rid of some compiler warnings 
I got stick for in builds of DBD::ODBC. If it is ok with you I'll commit 
it - I don't see it does any harm but as it is in Driver.xst and has the 
potential to break all DBDs I thought I'd check.

Martin

Index: t/10examp.t
===================================================================
--- t/10examp.t	(revision 14753)
+++ t/10examp.t	(working copy)
@@ -5,6 +5,7 @@
 use Config;
 use Cwd;
 use strict;
+use Data::Dumper;
 
 $^W = 1;
 $| = 1;
@@ -354,6 +355,14 @@
 ok( !eval { $se_sth1->execute } );
 like $@, qr/\[for Statement "select mode from \?" with ParamValues: 1='val1', 2='val2', 3='val3', 4='val4', 5='val5', 6='val6', 7='val7', 8='val8', 9='val9', 10='val10', 11='val11'\]/;
 
+eval {
+    local $se_sth1->{PrintError} = 0;
+    $se_sth1->execute(1,2);
+};
+unlike($@, qr/ParamValues:/, 'error string does not contain ParamValues');
+is($se_sth1->{ParamValues}, undef, 'ParamValues is empty')
+    or diag(Dumper($se_sth1->{ParamValues}));
+
 # check that $dbh->{Statement} tracks last _executed_ sth
 $se_sth1 = $dbh->prepare("select mode from ?");
 ok($se_sth1->{Statement} eq "select mode from ?");

Index: Driver.xst
===================================================================
--- Driver.xst	(revision 14753)
+++ Driver.xst	(working copy)
@@ -90,10 +90,12 @@
     SV *        attribs
     CODE:
     {
+    D_imp_dbh(dbh);
+#if !defined(dbd_db_login6_sv)
     STRLEN lna;
-    D_imp_dbh(dbh);
     char *u = (SvOK(username)) ? SvPV(username,lna) : "";
     char *p = (SvOK(password)) ? SvPV(password,lna) : "";
+#endif
 #ifdef dbd_db_login6_sv
     ST(0) = dbd_db_login6_sv(dbh, imp_dbh, dbname, username, password, attribs) ? &PL_sv_yes : &PL_sv_no;
 #elif defined(dbd_db_login6)