I recently agreed to take over DBD::CSV, as the previous maintainer admitted he had no time to work on it.

First things to do in these cases for me - right after creating a full-history git repository - is to browse through the source code, see if there are pieces of code marked with comments about TOD'd and possible failures. Right after that, I start applying perltidy (with my own .perltidyrc of course) and updating the docs and Change history as I go along. git commit is easy, so I leave a nice trail for myself in what I thing is improving the overall quality.

After code changes, of course I run the test suite, which in this case was rather weird. It was based on a system obviously not written to be just for this module, but to be some sort of drop-in test suite for all kinds off database modules.

That was only obscuring what was happening, so I removed all references to MySQL, Adabas, pNET and other unused pieces of the puzzle.

That cleared thing up in what was being tested, but it was still not the nice syntax I knew from Test::More, so a complete conversion was needed.

Starting with the basic test, I worked through the test files, and converted all test lines one-by-one to use Test::More, and after each chunk I re-ran the test suite to be sure I didn't break something.

One nice side-effect was that most of the global variables that were used in the old test suite could be removed. In this case the driver was always the CSV driver, so all conditional parts that assumed otherwise could be dropped.

At one point though, my (converted) tests suddenly started to fail. The old test looked like this:

    # Now try the explicit type settings
    Test($state or $cursor->bind_param(1, " 4", SQL_INTEGER()), 'bind 
+1')
        or DbiError($dbh->err, $dbh->errstr);
    Test($state or $cursor->bind_param(2, "Andreas König"), 'bind 2')
        or DbiError($dbh->err, $dbh->errstr);
    Test($state or $cursor->execute, 'execute binds')
        or DbiError($dbh->err, $dbh->errstr);
:
    Test($state or (($ref = $cursor->fetch)  &&  $id == 4  &&
                    $name eq 'Andreas König'))
        or printf("Query returned id = %s, name = %s, ref = %s, %d\n",
                  $id, $name, $ref, scalar(@$ref));
-->
t/40bindparam.t .... ok
[download]

and that passed all OK. So why should the new tests:

  # Now try the explicit type settings
  ok ($sth->bind_param (1, " 4", &SQL_INTEGER),   "bind 4 int");
  ok ($sth->bind_param (2, "Andreas König"),      "bind str");
  ok($sth->execute,                               "execute");
:
  ok ($sth->fetch,                                "fetch");
  is ($id,        4,                              "id   4");
  is ($name,      "Andreas König",                "name 4");
-->
t/42_bindparam.t ....... 2/40
#   Failed test 'id   4'
#   at t/42_bindparam.t line 75.
#          got: ' 4'
#     expected: '4'
# Looks like you failed 1 test of 40.
t/42_bindparam.t ....... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/40 subtests
[download]

suddenly fail?

I found out that it was a bug in DBD::File, where bind_param () just ignored the third (attributes) argument completely. I have a fix ready, but I am awaiting commit rights to the DBI repository.

The original test suite was written so complex to be versatile, that it did hide the real errors. Now how valuable is a test suite if it does not test what you think to test? It only adds to the confusion and to the time needed to debug when things go really really wrong.

In fact this is just a plea to use standard and proven test suites that all of us understand. They are probably a lot more reliable than whatever you come up with yourself, even if you are a seasoned programmer.