[Koha-bugs] [Bug 18974] Cataloging MARC21 record and adding item selenium test

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18974

--- Comment #19 from Jonathan Druart <jonathan.druart at bugs.koha-community.org> ---
(In reply to Victor Grousset/tuxayo from comment #18)
> (In reply to Jonathan Druart from comment #17)
> > I am not sure I understand.
> > Make the tests pass using the default framework will be a good first step.
> 
> The issue is that I wasn't getting the same record from LOC every time. And
> some have missing 040 and 245. Which doesn't comply with the default
> framework.
> 
> I've fixed this by searching for an ISBN instead of a title + author.

In a first step I'd not rely on network (so no search from LOC).

> > tuxayo:
> > > # Idea from the current cleanup(): (whose code seems mostly not related to
> > > this test)
> > > # - name the record specifically like test_cataloging_workflow
> > > # - delete it and it's related items
> > > # - question: isn't it risky about data integrity?
> > 
> > Data integrity? Why?
> 
> Due to direct SQL DB modification. Actually it's not risky, that just means
> I need advice from someone who knows what do delete to cleanup a record +
> item creation. i.e. In which tables they span + eventual stuff that the Koha
> data layer does.

I'd delete the item and record using selenium (click delete buttons).
Then you need: itemtype and branches. Actually will you know which data you
need to delete as you will have to create them.

> > > # Another idea:
> > > # - pick a random number and replace the ISBN by it
> > 
> > You can generate random data using TestBuilder is you like, then delete the
> > object and reuse the data, like:
> 
> Thanks, that will be handy for other tests. For this one, the need is more
> low level right? (A random ISBN to replace the one that came from Z39.50 to
> avoid collisions). So, easy also.
> 
> > In basic_workflow.t we use hardcoded values, that can work too.
> 
> It won't help here because the issue is when the test is ran twice.

It should not, if you cleanup if won't face issues if the test is ran several
times.

> But before going into this (cleaning up) or creating unique data that won't
> collide went test is ran twice: Should we rely on bug 19821 instead?
> That would block this patch and there other (less than a month, on maybe I'm
> too optimistic) but allow to not add and test code to handle cleanup.
> Including the case of the test that failed or was interrupted.

No, don't rely on bug 19821. You will have to cleanup anyway.
If the test explodes in mid-air there will be data that won't be removed. Don't
bother about that, it is how it works already.

> We aim for the new tests to be backportable right?
> If so, do you think bug 19821 could be backported? I can spend time on that
> for each branch (especially since I would like to improve the coverage down
> to my branch ^^) but not matter how much, I don't know if it would be OK
> from a QA POV.

Master first, usually enhancements are not backported.

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