853 epic review of ezid api test coverage

[sfisher]

This adds the tests mentioned in CDLUC3/ezid#853 .

I believe this now covers a fairly full set of functionality for the EZID API.

I also did a bunch of refactoring to make this object oriented since there were a lot of method taking parameters like base_url, user, password which we can just set as member variables on a class and use them from there without having to pass them all the time.

I removed the numbering since it's hard to maintain if we add or remove tests and adds complications I don't think are necessary. I just made things like heading and then indented underneath so it's clear how tests are related.

The command to run is the same as before but just asks many more tests.

[jsjiang]

Great work Scott!

A few things:

1. "Create or update identifier" - can we add "with update_if_exists=yes" to the subject so we know what it is doing. Also, can we run this test item after "Update identifier" so it will show up before "reserve and delete identifier"
2. We can remove checking background jobs from this script now
3. How about we change the script and class name to something like verify ezid status
4. The headless UI test is in the main but not this branch. Should we merge main to this branch first before merge it back to main? I am not sure.
5. I got an error while testing it on ezid-stg. Can you take a look.

Traceback (most recent call last):
  File "/apps/ezid/ezid-ops-scripts/scripts/verify_ezid_after_patching.py", line 562, in <module>
    main()
  File "/apps/ezid/ezid-ops-scripts/scripts/verify_ezid_after_patching.py", line 559, in main
    vap.check_resolver()
  File "/apps/ezid/ezid-ops-scripts/scripts/verify_ezid_after_patching.py", line 500, in check_resolver
    status = self._get_status(f"{base_url}/{id}", allow_redirects=False)
                                 ^^^^^^^^
NameError: name 'base_url' is not defined

Thank you

Jing

[sfisher]

Ok, I updated this again. It was weird since there were a few code changes missing which I thought had gotten committed.

• with "update_if_exists=yes" to the subject
• We can remove checking background jobs from this script now
• How about we change the script and class name to something like verify ezid status
• The headless UI test is in the main but not this branch. Should we merge main to this branch first before merge it back to main? I am not sure.
• I got an error while testing it on ezid-stg. Can you take a look.

[jsjiang]

@sfisher Hi Scott,
Since we have removed verifying background job status from the script, now we can run the test scripts from other locations outside of the EZID instances. How about we add a readme file to explain how to setup an environment to run the scripts.

Jing

[sfisher]

Ok. Well, the download is using a background job, which is why I wondered about it. For dev/local then it needs to be started for the tests to succeed.

What are your thoughts on this. Should the the download be automatically skipped on dev/localhost? Or should we start it up manually every time?

Also, where do you prefer these instructions? In this repo or in the ezid-docs-internal or both?

[jsjiang]

• Download against Dev: if we want to test it, then we need to manually start the job on Dev; otherwise we can ignore the error reported from the test script
• Running test on local using the test option: if the database is set to Dev in the settings, then it is equivalent to test against Dev.

For the instructions, we may want a readme in this repo and a how-to in the ezid-docs-internal. The readme will be focused on how to setup Python environment (or virtual environemnt) to run the scripts. For how-to, we already have a doc in the ezid-docs-internal repo and need update it accordingly after this release.

[jsjiang]

We can remove test from the test options if it doesn't make sense.

[jsjiang]

Regarding on readme: it is probably out of scope of this ticket. We can work on it in a future ticket while trying to figure out the best way or place to run the tests.

[sfisher]

I added a file scripts/README.md that documents how to install python and run the script for this test. We can expand information about how to run this for the other test(s) if we get to that.

It also seems like we might move toward either a container or github actions for running some tests where we could trigger as either part of a deploy or as a manual test from gh actions. In that case it could be a different model than running locally.

[jsjiang]

The tests are comprehensive and the instructions look great!
Thank you Scott!

Jing