On Thu, Sep 07, 2006 at 03:14:22PM +0100, Tim Bunce wrote: > > Here are some general areas that need work: > > - Increasing test coverage, It's pretty poor right now: > http://pjcj.sytes.net/cover/latest/DBI-1.52/coverage.html > Start with improving the subroutine coverage > > http://pjcj.sytes.net/cover/latest/DBI-1.52/blib-lib-DBI-pm--subroutine.html
I'll expand in this topic a little for Tielman, and anyone else who wants to help out with improving test coverage. (It's an important task and one that's easy to have multiple people working in parallel on different test scripts. You just need to post a note to [email protected] saying what area you'll be working on.) http://pjcj.sytes.net/cover/latest/DBI-1.52/coverage.html shows how much of the code in the DBI distribution is executed by the test suite. The colors are pretty, but all that red and orange means the test suite is doing a poor job. If code isn't even run by the test suite then obviously there's no way to know if it does the right thing or not. So the goal is to increase the amount of code tested by the test suite. The pretty coverage analysis acts as a guide pointing us to what needs testing. The analysis includes coverage summaries for various levels of detail: subroutine, statement, branch and condition. You can ignore branch and condition for now as it's very hard to get high coverage for those. The first priority is that every subroutine should be invoked by the test suite. You can see that currently there are lots of subroutines that never get called by the test suite: http://pjcj.sytes.net/cover/latest/DBI-1.52/blib-lib-DBI-pm--subroutine.html So for each one of those uncalled subs, one or more tests need to be written that call the sub and check it does/returns something reasonable. Now some random notes... - focus on subs/methods that applications use directly, ie parse_dsn and disconnect before NEXTKEY. - some may not be executed because it's implemented in DBI.xs (rows?) or the driver that's being used for the tests (ping?). For the first case moved the sub from DBI.pm into DBI::PurePerl. For the second, add tests that use a - Ignore code related to undocumented features (like the DbTypeSubclass connect attribute and the more_results method). - After picking off the easy subs from DBI.pm, take a look at some of the other modules, like DBI::PurePerl, DBI::Profile*, DBD::File - Then start looking at branch level coverage http://pjcj.sytes.net/cover/latest/DBI-1.52/blib-lib-DBI-pm--branch.html and see, first of all, if there are any 'important' branches not being tested. - Think about where new tests should go: add them to an existing test script only if that's the natural place for them, otherwise create a new test script. - Would be good to install Devel::Cover yourself so you can track your progress and be rewarded with a clear indication of progress. - Check in changes regularly. If you come across anything odd (I'm sure you will :) fire off an email to [email protected] and move on to testing some other method. I'll try to clarify asap. Thanks again! Tim. p.s. For the pedants, yes, I'm ignoring the fact that a poorly written test could exercise the code but not detect if the code does the wrong thing.
