Test download predicate parsing?

1

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.

1 Like
2

I’m not aware of such a service, but I think it’s good idea. Perhaps a simple flag in the request, e.g.

´´´

{
  "creator": "userName",
  "notificationAddresses": [
    "userEmail@example.org"
  ],
  "sendNotification": true,
  "format": "SIMPLE_CSV",
  "test": true,
  "predicate": {
...

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?

1 Like
3

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.

4

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.

Is api.gbif-uat.org exactly the same setup as api.gbif.org ?

5

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.

6

Thanks, will report back if I run into any issues

7

@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?

8

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.

9

thanks @MattBlissett

Sounds like you’re suggesting I use uat for downloads testing, but that I stick with api.gbif.org for all other testing.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.