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:
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) /wiki.evergreen -ils.org/ doku.php? id=dev: contributing: qa#pgtap_ database_ tests)
2) Run the pgtap tests (https:/