search

ualbertalib / jupiter

Jupiter is a University of Alberta Libraries-based initiative to create a sustainable and extensible digital asset management system. This is phase 2 (Digitization).
https://era.library.ualberta.ca/
MIT License
23 stars 10 forks source link

Improvements for EZID tests #1936

Closed murny closed 3 years ago

murny commented 3 years ago

Not sure what's going on with our EZID tests – seems like we have it disabled in test because we don't set the test shoulder, but also we have VCR cassettes for it, AND it has a test stub it provides?

Might be worth investigating what our current EZID tests are doing. Could be some improvements such as allowing miniting in tests? Is it possible to switch over to use the EZID test helper that the gem provides instead of providing a lot of this functionality ourselves?

# test/test_helper.rb

require "ezid/test_helper"
Ezid::TestHelper.ezid_test_mode!

Test helper code is found here: https://github.com/duke-libraries/ezid-client/blob/develop/lib/ezid/test_helper.rb

mbarnett commented 3 years ago

Just talked this over with Connor – we are minting in tests as far as we can tell at the moment, and the main thing Ezid::TestHelper.ezid_test_mode! seems to do is hardcode the API calls to Duke's Datacite test account and test shoulder, whereas we already have our own test account and test shoulder set up in secrets.yml, unless I'm missing something here?

murny commented 3 years ago

Probably should have captured more details when I wrote this as I forgot the "Why" for this issue.

I don't believe we are minting in tests. We currently have Rails.application.secrets.doi_minting_enabled = false set in tests. Enabling this, will just allow DOI jobs to get enqueued on the ActiveJob queue (these jobs will NOT run however, since this is a testing environment). We enable this in a few spots such as doi_service_test and soon items_controller_test (once this PR gets merged: https://github.com/ualbertalib/jupiter/pull/1930/files) to see if these jobs are being enqueued when something happens like when new item gets created, or reset DOI action takes place.

If we want to actually mint stuff, we interact directly with the DOIService class and we use VCR to mock out these external API calls.

This all seems fine to me? Not sure what the purpose of this ticket was other then just investigate into what we are actually doing with EZID and if its worth moving our dummy config over to the Ezid::TestHelper.ezid_test_mode! (which like you said might be no value). I suppose EZID also has a mock helper (https://github.com/duke-libraries/ezid-client/wiki/Mock-Identifier) but I think maintaining our own VCR tapes is probably better.

So feel free to close if nothing left to do here 🤔

mbarnett commented 3 years ago

We talked it over and decided the status quo is probably the simplest approach for the time being.