December 2002 - Koha-devel - lists.koha-community.org

opac-reserve.pl
by paul POULAIN 20 Jan '03

20 Jan '03

Hi finlay and others. The opac-reserve in cvs head does not work, and the one in 1.2 seems to be less developped. Maybe you've, at katipo a different version that could work :-) or at least know where are the bugs : Global symbol "$MAXIMUM_NUMBER_OF_RESERVES" requires explicit package name at /home/httpd/html/koha.dev/cgi Global symbol "@data" requires explicit package name at /home/httpd/html/koha.dev/cgi-bin/koha/opac/opac-reserve.pl line 221. Undefined subroutine &main::CalcReserveFee called at /home/httpd/html/koha.dev/cgi-bin/koha/opac/opac-reserve.pl line 94. (the 1st is fixed in cvs head with $MAX... = 5 at script beginning like in 1.2) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://fr.koha.org)

1 1

Koha and testing
by Pat Eyler 08 Jan '03

08 Jan '03

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' => 'ehs(a)pobox.com' > }; Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

3 2

koha and testing
by Ed Summers 06 Jan '03

06 Jan '03

Hi, I'm new to the koha-devel list (somehow forgot to subscribe a few weeks ago) and I'm interested in getting familiar with the Koha source code by writing unit tests for it. I guess I could go back through the archives and see what discussion I can find, but I was wondering if anyone could provide me with some guidance on how testing is being done currently, and good places to start looking at creating new tests. I've worked quite a bit with the Test::More framework, and would be interested in writing a 'smoke' program that would iterate through the available tests, run them, and report any failures. This process could even be automated, if it proves feasible. Anyhow, I just thought I'd express my interest and see if anyone has any ideas. -- Ed Summers aim: inkdroid web: http://www.inkdroid.org

2 2

1.3.3 NOT released !
by paul POULAIN 06 Jan '03

06 Jan '03

Hi, During chrismas holidays, i can't work a lot on my computer as you may have seen :-) The 1.3.3 could not be released before christmas, because of many installer problems. I just have spend 2 hours on it, and it still doesn't work well; so, the 1.3.3 will be released in january 2003 ! note that ppl using a cvs version should be able to test the uptodate version, as the remaining bugs are only on installer/db-updater/koha.conf creation. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://fr.koha.org)

2 2

Re: [Koha-devel] koha and testing
by Ed Summers 31 Dec '02

31 Dec '02

Hi Nathan: thanks for writing. 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 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. 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. > 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. Yes, these are important. I guess a test database will need to be up and running for alot of these sorts of tests. > 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. > > 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' => 'ehs(a)pobox.com' };

1 0

[Bug 84] broken link
by bugzilla-daemon＠wilbur.katipo.co.nz 27 Dec '02

27 Dec '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=84 chris(a)katipo.co.nz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 90] delbibitem.pl missing?
by bugzilla-daemon＠wilbur.katipo.co.nz 27 Dec '02

27 Dec '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=90 chris(a)katipo.co.nz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From chris(a)katipo.co.nz 2002-12-28 15:37 ------- Oh its already fixed in the main trunk :-) Fixed in rel-1-2 now, modbibitem.pl calls deletebiblioitem.pl ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 90] delbibitem.pl missing?
by bugzilla-daemon＠wilbur.katipo.co.nz 27 Dec '02

27 Dec '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=90 ------- Additional Comments From chris(a)katipo.co.nz 2002-12-28 15:08 ------- I think modbibitem.pl should actually be calling deletebiblioitem.pl http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/koha/koha/deletebiblioitem.pl Ill fix this in the main trunk. It uses C4::Biblio so cant be used in the rel-1-2 tree. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

Customizing Barcode Checkdigit Subroutine
by Larry Currie 22 Dec '02

22 Dec '02

Under our current library system, we use 14 digit patron barcodes, and the 14th digit is determined as follows: 1. Multiply every other digit starting with the leftmost by 2 and total the digits of any multi-digit product. Sum the resulting digits. 2. Add remainder of digits (every other digit starting with the second from the left). 3. Add result of step 1 and step 2 and substract the rightmost digit of the sum from 10 to obtain the check digit. Example: Given: 2 1 1 1 2 0 0 0 6 9 8 1 3 C (C to be determined) (mult by 2) 4 2 4 0 12 16 6 sum = 26 step 1 1 1 0 0 9 1 sum = 12 step 2 Step 3: 26 + 12 ----- 38 10 - 8 = 2 = check digit. Back in January, I tried to modify the checkdigit subroutine of Input.pm to fit our circumstances, but I'm not sure that my code was completely successful. Would anyone want to take a shot at modifying this subroutine to fit our circumstances, since we would like to use our existing patron barcodes in Koha? Larry Currie -- Lawrence W. Currie User Services Librarian California Academy of Sciences Golden Gate Park San Francisco, CA 94118 lcurrie(a)calacademy.org (415) 750-7108 (415) 750-7106 fax http://www.calacademy.org/research/library/

2 1

modif in gettemplate
by paul POULAIN 20 Dec '02

20 Dec '02

I just commited a little modif in gettemplate. It now auto-replaces theme and lang template variable. This is useful if you have images in your template : <img src="/<TMPL_VAR name="theme">/<TMPL_VAR name="lang">/images/picture.gif> or <img src="/<TMPL_VAR name="theme">/images/picture.gif> in the case of a non-language dependant image. Before this fix, gettemplate only replaced a variable called themelang, which was useful for language dependant images, but didn't work with theme-only images. Note the previous behaviour is still activated (ie : themelang still works) Note also that at the moment, "common" images are not managed (even small background pictures are copied in /en, /fr and /es languages directories. This will have to be fixed for 2.0. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://fr.koha.org)

1 0