Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create list of tests needed #26

Open
vsoch opened this issue Jul 2, 2020 · 7 comments
Open

Create list of tests needed #26

vsoch opened this issue Jul 2, 2020 · 7 comments

Comments

@vsoch
Copy link
Collaborator

vsoch commented Jul 2, 2020

hey @yarikoptic ! I've done just about all the changes / updates that I think are good for this first version, so please have it it / unlease the Yarik! Now is the right time to start review and tell me all the things I did wrong :) In all seriousness I always can quickly put together a first go, but then lots of tweaking / fine tuning / testing is needed. Actually, we don't technically have proper python tests, so if you want to make a list of tests to write I can go from there!

@yarikoptic
Copy link
Member

having tests would be great! but meanwhile I will follow up with a few separate "issues" on top of #22 (comment) initial experience

@vsoch
Copy link
Collaborator Author

vsoch commented Jul 2, 2020

okay! Let's prioritize tests though, since we don't have them (it makes me uneasy).

@vsoch vsoch changed the title Unleash the Yarik! Create list of tests needed Jul 2, 2020
@yarikoptic
Copy link
Member

yarikoptic commented Jul 2, 2020

What about starting with an integration test for sample use cases where sample input is provided and sample output is verified? vcr library then could be used to record any interaction which happen in that initial run (and committed as well, but be careful to not run with secrets in your environment variables)

Then as bugs are fixed - provide unit tests which code the fixed up behavior in corresponding functions

@vsoch
Copy link
Collaborator Author

vsoch commented Jul 3, 2020

Good idea - we will want to do this after adding support for some kind of --from or --lookup.

But no more today! Dinnertime!

@yarikoptic
Copy link
Member

as requested in #48 I think it would be useful to establish a "high level" unittest for verifying finding out correct ORCID ids.

  • Sample search queries could be
    • "Yaroslav Halchenko" and "Halchenko, Yaroslav" - should find 1 -- 0000-0003-3456-2493
    • ideally, search for unicode names, e.g. "Ярослав Олеговіч Гальченко" although that one is actually in "other-names"
    • "Zumbudda" - should find none AFAIK
    • "Horea Christian" is another one to test finding based on other-name if unicode search above cannot be supported
    • by an email:
e.g. for mine should find a single entry
$> curl --silent -X GET --header 'Accept: application/json' 'https://pub.orcid.org/v3.0/expanded-search?q=email:[email protected]' | jq .
{
  "expanded-result": [
    {
      "orcid-id": "0000-0003-3456-2493",
      "given-names": "Yaroslav",
      "family-names": "Halchenko",
      "credit-name": null,
      "other-name": [
        "Ярослав Олеговіч Гальченко"
      ],
      "email": [
        "[email protected]"
      ],
      "institution-name": [
        "Center for Open Neuroscience",
        "Dartmouth College",
        "Debian Project",
        "New Jersey Institute of Technology",
        "Rutgers University",
        "University of New Mexico",
        "Vinnytsia State Technical University"
      ]
    }
  ],
  "num-found": 1
}
FWIW - it can even do glob matching in email address seems to me giving information that there are 30k records with gmail.com and 121k records with some email address:
$> curl --silent -X GET --header 'Accept: application/json' 'https://pub.orcid.org/v3.0/expanded-search?q=email:*@gmail.com' | jq . | grep num-found
  "num-found": 30073

$> curl --silent -X GET --header 'Accept: application/json' 'https://pub.orcid.org/v3.0/expanded-search?q=email:*' | jq . | grep num-found     
  "num-found": 121636
- since interface does not require authentication, those tests could use `vcr` library to record transactions (and to be committed) so subsequent test runs would just reuse recorded tapes. I think it should be overall beneficial to not abuse orcid interface, while still testing cli/tributors code itself. Once in a blue moon (weekly?) there could be a test run which would ignore the tapes and does it "fully" thus testing if any changes in underlying returned results changed or API was deprecated etc.

@vsoch
Copy link
Collaborator Author

vsoch commented Aug 4, 2020

I can add this to the PR! Can you tell me more about what you mean by using the vcr library to "record transactions" (I'm not familiar with this). My basic intuition would be to add a few tests for the list you generated, to be run on a PR, which I don't think would be abusing the API. What tapes?

@yarikoptic
Copy link
Member

https://vcrpy.readthedocs.io/en/latest/
FWIW, we use it in datalad for some tests and have helper: https://github.com/datalad/datalad/blob/master/datalad/support/vcr_.py#L44 but most likely you don't need anything like that ;)

@yarikoptic yarikoptic removed their assignment Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants