[Investigate] Update caas-aspace-scripts for Automatic Testing Data R…

[lorawoodford]

…etrieval/Use #58

Description

Letting this PR serve as a starting point for discussion on how to handle testing at a larger scale. What I'm proposing here is, at a high level:

• adopting the use of vcrpy to record API responses from external systems (aka ASpace) and store those recordings in this repo
• adding tests to github actions

What this workflow would look like moving forward is as follows.

1. A CAAS team member is assigned to create or substantially update a new script in this repo
2. The team member runs testing on their local machine running against a local instance of ArchivesSpace pre-populated with the necessary records/settings/etc. required to test out the functionality of the script
3. When ready, the developer records a vcr cassette of this passing functionality (steps will be provided on how to do so)
4. The developer then commits those cassettes to the repository alongside the new script(s) and test(s)
5. Moving forward, these tests will run (both locally and in CI) against these recordings and will not require a running instance of ArchivesSpace
6. VCR cassettes will only need to be re-recording when there is a substantial change in the functionality or underlying data structure of ArchivesSpace, and the need to re-record those cassettes should be identified in the story/task at the time of refinement or development of the script

Some opinionated choices I've made here that are worth pointing out:

• test/vcr_utils.py sets our initial vcr configurations, including:
  • obfuscating ASpace API passwords and tokens in any recordings - this should really never be an issue since we'd be recording against local/dummy instances of ArchivesSpace, but seemed a worthwhile failsafe in case someone accidentally did record against a living instance of ASpace with real credentials
  • setting the filepath and naming conventions for the cassettes (storing them in test/fixtures/vcr_cassettes/{script_file_name}/{test_class_name}.yaml
• Setting the python version used in CI to 3.11. This is just arbitrary and can be changed, but is what I'm using locally at least.
• Adding a test-requirements.txt that'll hold just test-related dependencies (at present, only vcr)
• Reorganizing the tests into a test directory from the tests directory in order to get unittest to successfully discover the tests
• Similarly, modifying the filename of the one updated test to begin with test_*, again, so that unittest can autodiscover it

Likely follow on tasks (should we deem this the path forward we'd like to pursue):

• Add documentation on how to record/re-record cassettes to this repo's wiki
• Determine whether or not we need to create a "source of truth" db and/or API collection in order to bootstrap bulk re-recording tests no matter the developer (in theory, this isn't necessary, but it might be a nice-to-have)
• Investigating whether everything currently in requirements.txt needs to be there (it's being called in CI now, so we may want to just generally keep aware of what's in and what's not in there)
• Consider caching in CI if we do want to keep all those dependencies available
• Document how we'll adopt this moving forward. This PR only updates one specific test. Do we want to also take a bit of time now to update others, or only address them as we need to on an ad hoc basis when changes or features are added?

Related GitHub Issue

#58

Testing

See tests in CI

Checklist

• ✔️ Have you assigned at least one reviewer?
• 🔗 Have you referenced any issues this PR will close?
• ⬇️ Have you merged the latest upstream changes into your branch?
• 🧪 Have you added tests to cover these changes? If not, why:
• 🤖 Have automated checks (if any) passed? If not, please explain for the reviewer:)
• 📘 Have you updated/added any relevant readmes/wiki pages/comments in the codebase?
  ⚠️ Follow-on task to be filed. This is just an investigation/discussion starter.
• 📚 Have you updated/added any external documentation (e.g. Confluence, AirTable, GitHub Projects)?
  ⚠️ Follow-on task to be filed. This is just an investigation/discussion starter.

[lorawoodford]

@crugas Hoping this can serve as a starting point for discussions moving forward. No rush on this since this was just an investigation and I feel like I've "investigated" it and documented what I need to at this juncture, but want to keep things moving.