https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18974 --- Comment #19 from Jonathan Druart <jonathan.druart@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.