http://qs321.pair.com?node_id=760961


in reply to Re: Using standard testsuites
in thread Using standard testsuites

I think that specifically binding types to parameters/variables - and accepting them in the calls - kinda promises the end-user that the types will be honored. In this case, the bug isn't really in DBD::CSV, but in DBD::File, and I have meanwhile commited a patch that applies basic types in these cases when they are requested.

Unless speified in one way or another, DBD::CSV would of course not be able to set those types itself when reading/analyzing files.

I'm now done with the conversion to Test::More, and found out that this process at least fixed one RT bug along the way.

Devel::Cover by the way is a great tool to craft TODO lists :).

Update: More important, related to the original post, it was tested for, so even the original author was expecting it to work, but the tests didn't test what it was supposed to test, and thus hiding the bug. Documented or not, this is very very unwanted behaviour.


Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re^3: Using standard testsuites
by rir (Vicar) on Apr 30, 2009 at 20:32 UTC
    binding types ... kinda promises ... the types will be honored.

    You are right but there are other aspects. If I pull a record, change someone's middle initial, then update the record; do I want a ' 4' to be corrected to a canonical '4'? Will all the other programs using my CSV file approve? There That is an argument for least change.

    When one tightens up on type handling, little problems start popping up. Often they keep popping up.

    Incidentally, the test changed: SQL_INTEGER() and &SQL_INTEGER can differ semantically.

    Be well,
    rir

      A middle initial is rather unlikely bound to be an initial, right? If unbound. nothing changes.

      I have no intention to break anything. I want to fix bugs, and extend features.


      Enjoy, Have FUN! H.Merijn