search

mattroumaya / surveymonkey

Access your SurveyMonkey data directly from R!
https://mattroumaya.github.io/surveymonkey/
Other
42 stars 10 forks source link

Add test coverage #51

Closed sfirke closed 2 years ago

sfirke commented 4 years ago
jamieRowen commented 2 years ago

@mattroumaya, continuing conversation from #90 here. I guess if you want to start catching changes to the API you would need to actually make a request to obtain the data.

Since you likely only have a limited number of requests you probably don't want to do this on every push, so would run tests that require this on PR to master/main only.

Since this would get in the way of running tests as part of local dev, you could also have a local copy of the raw survey monkey api resources for testing, which i believe is what you already do for the test on parse_respondent_list against which all of your tests can execute. Your check that the API hasn't changed could then just compare returned raw against those local files on PR. With this approach you would get the ability to check most of your tests as a developer on your own machine and on each push to a branch if you wanted, and on PR could finally check that the raw files you have been testing against match those that you have. This should largely be fine on the assumption that the API will change less often than the package at this point in time.

jamieRowen commented 2 years ago

To add to this, if you can give me some example of test survey and expected results I don't mind adding some tests when I get time. If you can find a way to give me a token I can use for testing purposes as well I can add it to a github action.

sfirke commented 2 years ago

Since this would get in the way of running tests as part of local dev, you could also have a local copy of the raw survey monkey api resources for testing, which i believe is what you already do for the test on parse_respondent_list against which all of your tests can execute.

This makes sense to me. The small suite of existing tests uses this approach as you note. To do this, I think someone should make a dummy survey with lots of question types, fill it out with responses in a way that gets at a mix of cases (incomplete response, everyone skips the same question, etc.) and then its transformation could be tested.

I guess if you want to start catching changes to the API you would need to actually make a request to obtain the data.

Good idea. The issue I see is storing API keys in the repo in a safe way. I guess this could be possible, the way that one can store a secret key for Codecov as a Github variable? But I think it would require someone with a paid SurveyMonkey account to add their account's credentials for this purpose.

jamieRowen commented 2 years ago

This makes sense to me. The small suite of existing tests uses this approach as you note. To do this, I think someone should make a dummy survey with lots of question types, fill it out with responses in a way that gets at a mix of cases (incomplete response, everyone skips the same question, etc.) and then its transformation could be tested.

For a number of endpoints we could do something using {httptest} to mock API responses based on the examples surveymonkey give you in their API docs.

Good idea. The issue I see is storing API keys in the repo in a safe way. I guess this could be possible, the way that one can store a secret key for Codecov as a Github variable? But I think it would require someone with a paid SurveyMonkey account to add their account's credentials for this purpose.

Yeh you should be able a key in the same way, for a pipeline it's then just a case of knowing what the key is called and setting up appropriately.

I had a quick look around survey monkey API docs to see if there was something that could be done. It does suggest that some public apps get a key with unlimited API calls. I wonder if sending them an email asking for a token that could be used for testing an API wrapper library would be productive.