[Koha-bugs] [Bug 9842] New: SIP tests : fix for 07hold.t on Cancel Hold

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9842

            Bug ID: 9842
           Summary: SIP tests : fix for 07hold.t on Cancel Hold
    Classification: Unclassified
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: ASSIGNED
          Severity: trivial
          Priority: P5 - low
         Component: SIP2
          Assignee: adrien.saurat at biblibre.com
          Reporter: adrien.saurat at biblibre.com
                CC: colin.campbell at ptfs-europe.com

[MT10401]
When running the SIP tests, 07hold.t returns errors.

ERROR 1:
#   Failed test 'match leader Place Hold: valid item (1783B), valid patron
(1X981)'
#   at /home/asaurat/workspace/versions/community/C4/SIP/t/SIPtest.pm line 204.
# Response '161N20130318    181053AA1X981|BSVIL|AB1783B|AJL ANGOISSE DU ROI
SALOMON|AOVIL|AY3AZEA76' doesn't match pattern '(?-xism:^161Y\d{8} {4}\d{6})'

Here, the most important return value is the "1" after "16", indicating a
success.
And indeed, the hold is correctly recorded in Koha.
The following character, indicating the "available" status (and which can be of
"Y" or "N" value), is fed by the "available" method in C4/SIP/ILS/Item.pm which
is not totally functionnal yet.
So, the question is :
- should the test gives a OK result by accepting N or Y as long as we get a 161
and not a 160?
- should we keep this as it is? (seems safer and cleaner, if we want to respect
the SIP protocol the item should be marked as available if it is... I'll go
this way and won't touch this in this patch)

ERROR 2:
#   Failed test 'match leader Cancel Hold: valid hold for user (1X981)'
#   at /home/asaurat/workspace/versions/community/C4/SIP/t/SIPtest.pm line 204.
# Response '160N20130318    181054AA1X981|AOVIL|AFNo such hold on patron
record.|AY6AZEA73' doesn't match pattern '(?-xism:^161[NY]\d{8} {4}\d{6})'

Here, the hold actually exists, but the "No such hold on patron record" result
is caused by an error in the perl script of ILS.pm
Tests like "unless ($trans->ok)" should be written unless "($trans->ok(1))".

ERROR 3:
#   Failed test 'match leader Cancel hold: cleanup hold for 2nd patron (1X999)'
#   at /home/asaurat/workspace/versions/community/C4/SIP/t/SIPtest.pm line 204.
# Response '160N20130318    181054AA1X999|AOVIL|AFNo such hold on patron
record.|AY0AZEA70' doesn't match pattern '(?-xism:^161[NY]\d{8} {4}\d{6})'

Same as error 2.

I'll thus include a small patch correcting the "No such hold on patron record"
problem (ERRORS 2 and 3).
For the first error, I don't know how to finish the "available" method so I'll
leave it to someone who knows this part better. Maybe can it be assumed that if
we get a 161 the following character is automatically Y? After all,
this Y or N on availability seems to be a concern only when the hold is
refused.
Or maybe should we accept both Y and N because it is possible to place a hold
on items not yet available?
I don't know...

TEST PLAN :
1) In "C4/SIP/t", configure the SIPtest.pm file.
2) Configure your SIPconfig.xml if needed.
3) Start your SIP server.
4) In "C4/SIP/t", do a "make test" (see the README file for more informations)

-- 
You are receiving this mail because:
You are watching all bug changes.