t/db_dependent/Labels/t_Batch.t depends on the Jenkins database. We should create the data we want and delete them at the end.
Created attachment 18384 [details] [review] Bug 10333: Labels/t_Batch.t needs to create its own data prove t/db_dependent/Labels/t_Batch.t [14:53:09] t/db_dependent/Labels/t_Batch.t .. 1/32 # Testing Batch->new() method. t/db_dependent/Labels/t_Batch.t .. 13/32 # Testing Batch->retrieve() method. t/db_dependent/Labels/t_Batch.t .. ok All tests successful. Files=1, Tests=32, 3 wallclock secs ( 0.02 usr 0.00 sys + 0.48 cusr 0.03 csys = 0.53 CPU) Result: PASS
Created attachment 18399 [details] [review] Bug 10333: Labels/t_Batch.t needs to create its own data prove t/db_dependent/Labels/t_Batch.t [14:53:09] t/db_dependent/Labels/t_Batch.t .. 1/32 # Testing Batch->new() method. t/db_dependent/Labels/t_Batch.t .. 13/32 # Testing Batch->retrieve() method. t/db_dependent/Labels/t_Batch.t .. ok All tests successful. Files=1, Tests=32, 3 wallclock secs ( 0.02 usr 0.00 sys + 0.48 cusr 0.03 csys = 0.53 CPU) Result: PASS Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
With this patch, the tests now assume that the home and holding branch are in 952 a and b. While this is the Koha default, it's not necessarily true. I think it would be better to get the values for these fields using GetMarcFromKohaField().
Created attachment 19201 [details] [review] Bug 10333: Labels/t_Batch.t needs to create its own data (In reply to Kyle M Hall from comment #3) > With this patch, the tests now assume that the home and holding branch are > in 952 a and b. While this is the Koha default, it's not necessarily true. > > I think it would be better to get the values for these fields using > GetMarcFromKohaField(). I use a DB with sample data, but you are right, it is not necessary to add this constraint. This new patch uses C4::Biblio::GetMarcFromKohaField and executes sql queries in a transaction.
Looks like this patch needs re-signed off.
# Testing Batch->get_attr() method. # Testing Batch->add_item() method. # Testing Batch->retrieve() method. # Failed test at t/db_dependent/Labels/t_Batch.t line 100. # Structures begin differing at: # $got = '-2' # $expected = C4::Labels::Batch=HASH(0x3aaa5b8) # Retrieved batch object FAILED to verify. # Testing Batch->remove_item() method. # Failed test at t/db_dependent/Labels/t_Batch.t line 109. # Structures begin differing at: # $got = '-2' # $expected = C4::Labels::Batch=HASH(0x3aaa5b8) # Updated batch object FAILED to verify. # Testing Batch->delete() method. # Looks like you planned 33 tests but ran 13. Do I need some setup first?
(In reply to Srdjan Jankovic from comment #6) > Do I need some setup first? No, this should be done by this unit tests file.
Created attachment 20276 [details] [review] Bug 10333: remove_item should be called just one time If there is no remaining items, the retrieve routine returns -2.
# Testing Batch->new() method. # Testing Batch->get_attr() method. # Testing Batch->add_item() method. Use of uninitialized value $encoding in string eq at C4/Biblio.pm line 3281. Use of uninitialized value $encoding in pattern match (m//) at C4/Biblio.pm line 3301. # Testing Batch->retrieve() method. # Failed test at t/db_dependent/Labels/t_Batch.t line 100. # Structures begin differing at: # $got = '-2' # $expected = C4::Labels::Batch=HASH(0x2df33c0) # Retrieved batch object FAILED to verify. # Testing Batch->remove_item() method. # Failed test at t/db_dependent/Labels/t_Batch.t line 108. # Structures begin differing at: # $got = '-2' # $expected = C4::Labels::Batch=HASH(0x2df33c0) # Updated batch object FAILED to verify. # Testing Batch->delete() method. # Looks like you planned 24 tests but ran 14. # Looks like you failed 2 tests of 14 run.
(In reply to Srdjan Jankovic from comment #9) > Use of uninitialized value $encoding in string eq at C4/Biblio.pm line 3281. > Use of uninitialized value $encoding in pattern match (m//) at C4/Biblio.pm > line 3301. I have no idea where is the problem. But there 2 lines intrigues me. $encoding is C4::Context->preference("marcflavour"). Don't you have the marcflavour syspref in your DB?
Yes, I was doing something else and removed the syspref erroneously. When I put it back there are no warnings. But the test failures stayed. Do you need any more details eg table dumps?
(In reply to Srdjan Jankovic from comment #11) > Yes, I was doing something else and removed the syspref erroneously. When I > put it back there are no warnings. > But the test failures stayed. Do you need any more details eg table dumps? I read the code but I have no idea why they don't pass. First step, the batch is created and the batch_id is backed-up into the $batch_id var. Items are added to the batch and the retrieve method returns -2 if the batch does not contain items. Maybe could you warn the $batch_id var (l. 56)? Should be > 1. To check if items have been added could be interesting too (SELECT * FROM creator_batches WHERE batch_id = $batch_id).
Created attachment 20454 [details] [review] Bug 10333: Labels/t_Batch.t needs to create its own data prove t/db_dependent/Labels/t_Batch.t db_dependent/Labels/t_Batch.t .. 1/33 # Testing Batch->new() method. db_dependent/Labels/t_Batch.t .. ok All tests successful. Files=1, Tests=33, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.34 cusr 0.00 csys = 0.37 CPU) Result: PASS Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
C4::Items::AddItemBatchFromMarc was failing (no records returned), I had no CPL branches. You may wish to add some check there, but om if you don't (it's that testing data bug request that is still being discussed).
Created attachment 20593 [details] [review] [PASSED QA] Bug 10333: Labels/t_Batch.t needs to create its own data prove t/db_dependent/Labels/t_Batch.t db_dependent/Labels/t_Batch.t .. 1/33 # Testing Batch->new() method. db_dependent/Labels/t_Batch.t .. ok All tests successful. Files=1, Tests=33, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.34 cusr 0.00 csys = 0.37 CPU) Result: PASS Signed-off-by: Srdjan <srdjan@catalyst.net.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Pushed to master. Thanks, Jonathan!
This patch has been pushed to 3.12.x, will be in 3.12.6. Thanks Jonathan!