-
Notifications
You must be signed in to change notification settings - Fork 6
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
Tests #18
Comments
👍 |
Hiya folk, I saw the thread on rOpenSci submission. In case it helps, I've got an example of using secrets on github actions here - you should pretty much be able to copy that general approach to get a private MAPBOX token into your test environment. |
Finally taking a looking at this. |
Heads-up @mpadge I think the commits above fixed the issue. Issue now is that Any ideas how to fix that? Seems that any package with an |
E.g.: failing tests on osmdata https://github.com/ropensci/osmdata/runs/2139987665 |
And all may be fixed when Mac binaries are rebuilt hopefully. |
Timetable for full alignment in on main |
The aim of testing code is to determine that it is 'fit for use'.
The key thing that should be tested in this package, I think, are whether the slopes returned are 'correct'. Key to that assessment is having a 'ground truth' of data with correct slopes. I think the test dataset with slopes from ArcMap provides a good starting point, but wonder if there is a more definitive way to testing that the slopes are right?
May be worth looking at old papers on slope calculation.
From the perspective of rOpenSci, there are clear recommendations:
All packages should have a test suite that covers major functionality of the package. The tests should also cover the behavior of the package in case of errors.
It is good practice to write unit tests for all functions, and all package code in general, ensuring key functionality is covered. Test coverage below 75% will likely require additional tests or explanation before being sent for review.
We recommend using testthat for writing tests. Strive to write tests as you write each new function. This serves the obvious need to have proper testing for the package, but allows you to think about various ways in which a function can fail, and to defensively code against those. More information.
The text was updated successfully, but these errors were encountered: