[Koha-devel] Koha and testing

[Pat Eyler]

Ed Summers wrote:
> Hi Nathan: thanks for writing.

And thanks for kicking off this thread Ed.  This is one of the places
I'd really like to see Koha do better, and it's going to take the
efforts of several people.

>
> On Tue, Dec 31, 2002 at 12:44:11PM -0500, Nathan Gray wrote:
> > I would prefer to use Test::Debugger over Test::More.  I like the
> > interface of Test.pm, though it doesn't handle all the scenarios I
> > need.  I wrote a new version of Test.pm, but Test::More beat me to
> > CPAN.
>
> I've use Test::More quite a bit, and have really come to like it. It
> also comes standard in Perl 5.8 now. I could adapt to another
> framework though, as long as it works :)

I'd just as soon we stuck to a standard part of the Perl distro.  The
fewer bits people need tograb to make Koha work the better (although
this is easier now that Mike's built the bundle for us.)

>
> > I am uncertain whether it would be better to have a small set of test
> > scripts with each module, or to have one large test suite in a
> > central location.  I'm leaning toward a centralized test suite, but
> > haven't grasped Koha enough to know where to start, or where the test
> > suite should be kept.
>

If you grab Koha from CVS, all the tests (what few there are) are in
the t subdir of the top level directory.  Once 2.0 is out the door,
we'll start working on the great reorg that will become 2.2 and we can
look at breaking modules into functional groups and including tests
with the individual modules.

> Yes, I'm unclear on this as well. In my current work environment we've
> adopted the former approach: to have component tests that are easily
> paired with the components they test:
>
>     C4/Format.pm
>     C4/Format.t
>
> Then we have a 'smoking' program which goes and looks for all the *.t
> files and runs the tests. Having them split out like this is extremely
> useful when adding new functionality: because you know exactly where
> you have to go to add or modify a test. It also uses the filesystem to
> illustrate which components lack tests.
>

This is a great model.  I'd like to get to the point where smoke tests
are run before cvs commits are made, on a nightly basis (reported to a
web page and/or mailing list), and prior to rolling a new release
(reported to a file in the release docs).  We have a ways to go before
we get there, but it makes a nice, comforting dream.

> > Definitely all the modules which interact with the database should
> > have tests to make sure selects, updates, deletes, inserts are all
> > working correctly.
> >
> > Likewise, any module which performs searches should have tests to make
> > sure that the correct information is returned, in the correct order.
> >
> > A test should make sure the templating system works, especially for
> > the various languages which are going to be supported.
>

I rally agree with the first two, but the third isn't too big a deal
to me.  Since we're using HTML::Template (which is pretty well
tested), I feel comfortable with some cursory tests of HTML output.
If we could get to the level of testing allowed by the Narf html/cgi
library in ruby, I could be convinced to change my mind.

> Yes, these are important. I guess a test database will need to be up
> and running for alot of these sorts of tests.
>

/me nods.  We do have a test DB dataset for just this purpose.  I
don't know that it's up to date for 1.3/2.0, but I'm guessing that it
is ... Paul is pretty thourough.

> > Let me know what your ideas are.  Pat Eyler will be overjoyed to have
> > another tester on board!  We'll hear from him as soon as the holidays
> > are past, I am assuming.  He is very good about writing.
> >

Yes, I am overjoyed.  Welcome aboard.

Before they're over even.

Don't listen to Ed about this ... the holidays have left him in too
good a mood and he's telling stories.


Happy New Year,
-pate

> > I hope to have Test::Debugger on CPAN in a day or three.
>
> OK, I look forward to seeing it. I know what you mean about getting
> bogged down in work. I feel the same way, but I want to find time to
> work on this.
>
> //Ed
>
> --
>
> % perl -MData::Dumper -e "print Dumper($me)"
> $VAR1 = {
>           'WEB' => 'http://www.inkdroid.org',
>           'NAME' => 'Ed Summers',
>           'AIM' => 'inkdroid',
>           'EMAIL' => 'address@hidden'
>         };

Pat Eyler
Kaitiaki/manager               migrant Linux sys admin
the Koha project               ruby, shell, and perl geek
http://www.koha.org            http://pate.eylerfamily.org