I don’t currently have unit tests in
rgbif to determine if download predicates built by users will actually work. I could kick off actual downloads in tests, but that doesn’t seem like a good idea to hit the download service in tests.
Is there an API end point for testing download predicates that does not kick off downloads? That is, I want to test that download requests coming from
rgbif are formatted correctly and parsed successfully by GBIF, but not kick off real downloads.
I’m not aware of such a service, but I think it’s good idea. Perhaps a simple flag in the request, e.g.
and then return 201 if successful? I guess it might also be set in the header to test the validity of the entire payload.
@MattBlissett, any comments or thoughts?
There’s nothing at the moment, maybe we should add something.
You can use api.gbif-uat.org for tests, which at least avoids creating real DOIs for each download. With an HTTP DELETE request, a download can be cancelled. This would be necessary after each test, as there’s a maximum of three concurrent downloads per user.
Thanks @dnoesgaard - that’s a good idea to have a boolean to toggle
Thanks for that idea @MattBlissett - I’ll probably try that, using
api.gbif-uat.org. And good idea to delete them after testing. I need to fix something in my vcr package, which should be done soon, then I can cache test fixtures for these tests. But definitely should remake them often in case you all change things on your side in terms of how queries are parsed.
api.gbif-uat.org exactly the same setup as
api.gbif-uat.org is supposed to be the same as api.gbif.org, although on occasion we may run our own testing – in that case, pieces can be broken or running the next version of a GBIF service.
Downloads use parts of the occurrence API and the registry, and it’s unusual that these would be unavailable on UAT.
Thanks, will report back if I run into any issues
@MattBlissett Thinking about this some more, should unit tests for pygbif and rgbif in general (for all their unit tests) use
api.gbif-uat.org instead of
api.gbif.org ? or do you think it’s a good idea to test against what users are actually using?
api.gbif-uat.org generally uses the same software versions as api.gbif.org, so should be used for all testing that would make changes – e.g. creating downloads. The system is smaller, and has fewer occurrence records, and can be slower.
Sometimes, UAT will be running a slightly newer version, but in that case it’s likely that we plan to run it in production soon.
Sounds like you’re suggesting I use uat for downloads testing, but that I stick with
api.gbif.org for all other testing.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.