Add some automated tests for 979 ISBNs

Here is a branch: user/sandbergja/lp1857060_tests_for_979_isbns

Not adding the pullrequest tag just yet, because I'd like to run it by the new developers group in January.

Just a note that this branch is ready to go.

And also, from my analysis, there was hardly any code that did not accept 979 ISBNs. This branch just fixes one piece of Perl (Amazon Added Content), and adds a few unit tests.

If there are 979 ISBN issues that I missed, let me know!

Jane,

Can you give specifics about what needs to be tested for the 979 ISBNs?

I am assuming it should be a legitimate ISBN so I am trying to find real ones. Locating books with the prefix has not been productive. I found one, 9791843123391, but it also has a 978 prefix 020-- which of course I can remove from the record for testing purposes. I don't have access to Books in Print....

I checked new releases up to April of 2021 and so far all have 9780 or 9781. If they have started assigning 9798 to US books, it hasn't been to many yet!

Elaine, first I found a self published one from November 2020 on Amazon with a 979-8 ISBN, but it wasn't in OCLC.

Believe it or not, I then tried WorldCat with ISBN: 979-8* and got lots of records, and did quickly spot a legit, English language book in there, a self-published novel with ISBN 9798671981742, OCLC number *1194875103.

Then I spotted one that said held by my library (didn't think to check THERE, LOL) ISBN 9798646193330 OCLC *1169783013. It's also self-published.

Also, 9798640423686 OCLC *1156966368, from Bregdan Publishing, we cataloged it in October.

Jane, these 2 in our catalog (Evergreen 3-4-5) seem to be working fine? What are we looking for here?

I have never used the wild card * in an OCLC search (aging myself since I learned OCLC searching when when they didn't allow such things, nor keyword searching!) and didn't even think of using it for an ISBN search. THanks for the tip!

Very, Very interesting that they are self-published. I wonder of publishers purchase enough ISBNs in advance tht they don't yet need the 9798s.

Elaine, I agree, and I wouldn't have tried it in Connexion, but we have a link to search WorldCat just through a web browser, and after I looked the first book that I found on Amazon without success, I wondered what it would do if I tried the wildcard there. I was actually shocked that it worked, then even more shocked that it brought up hits in my own library.

Ahh-- worldcat.org I never think of that

Tried 9798* as an ISBN search in Connexion client and got lots of hits. Most are self-published.

Lots of examples to test when we hear what we need to test.

Changed the name of this ticket to be a bit more accurate. My branch is mainly just automated tests to make sure that we don't introduce any future logic that wouldn't work with 979 ISBNs. I don't believe there is any part of the interface (except possibly Amazon added content) that, say, would display an error on a 979 ISBN. More of a preventative/quality assurance type measure.

So, a testing procedure for somebody with command line access to an Evergreen system would probably just be:

1) Run the Perl Unit Tests (https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa#perl_unit_tests)
2) Run the pgtap tests (https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa#pgtap_database_tests)

Thanks for putting this together Jane. I ran the tests and things looked good to me. Signoff is here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1857060_signoff / working/user/jboyer/lp1857060_signoff

Pushed to master, rel_3_7, and rel_3_6. Thanks, Jane and Jason!