unit tests for neotoma - Githubissues

ropensci / neotoma

Programmatic R interface to the Neotoma Paleoecological Database.

https://docs.ropensci.org/neotoma

Other

30 stars 16 forks source link

unit tests for neotoma #26

Closed gavinsimpson closed 10 years ago

gavinsimpson commented 11 years ago

As the examples in neotoma are encased in \dontrun{}, the package needs some unit tests to avoid changes in one function that breaks other functions.

Whatever solution is chosen, for submission to CRAN some checks may need to be skipped if the time taken to query Neotoma results in too long a package check time.

sckott commented 11 years ago

Agreed, tests are needed. We usually just use tests for local development since all package make web API calls, and we don't want tests failing on the occasional checks on CRAN servers.

gavinsimpson commented 11 years ago

There was a discussion some months ago, on R-Devel, about how to control extra checks that you want to run when running R CMD check but not have them run for CRAN when they do the same. IIRC there was a variable that could be checked for when running tests and the extra tests turned off accordingly. I'll try to find the discussion and outcome again.

karthik commented 11 years ago

What about adding tests into the tests folder to run separately? Each test can be set to fail gracefully (ie. not run) if it can't find an API key in the rprofile.

gavinsimpson commented 11 years ago

@karthikram Yes, ./tests is the place for these things. For other rOpensci packages that need an API key your suggestion could easily be arranged - though it would be better if the functions in the respective packages failed gracefully when no API key was found rather than something worked into the unit tests - i.e. print a message and return rather than error out.

For neotoma, which doesn't need an API key the checks would run all the time. I want that as I develop packages so I can see what fails but Neotoma isn't quick to respond and CRAN might be peeved about the check time. I don't know if I'm worrying about this too much or not - need to branch the code and make all the examples runnable and time them.

SimonGoring commented 11 years ago

Some ideas for tests:

I think that API call tests might not be too useful because of the time requirement, but we could pass out a couple easy ones. The other option is to have some RData files in the test directory that mimic the JSON data returned from API calls for particular sites. Then we could just pretend that the API call works, & see if the rest of the data processing does what it's supposed to do. That means that we need to re-form the functions to take out the API call and put it into a more general function. This is probably useful in that it would make cleaner code.
compile_list tests should be straightforward, we keep two pollen data sets in RData format in the test directory.

SimonGoring commented 10 years ago

I've added tests (a while ago, I'll check when exactly), but will keep adding them. I'm going to close this now and create individual issues for things that explicitly need tests.