Closed Robinlovelace closed 3 years ago
Exciting update, after the commit above, we're now on 5%, 70 more percentage points to go!
👍
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 sf
does not work on Mac, e.g. as shown here: https://github.com/ITSLeeds/slopes/runs/2143877715?check_suite_focus=true
Any ideas how to fix that? Seems that any package with an sf
dependency will fail on actions...
E.g.: failing tests on osmdata https://github.com/ropensci/osmdata/runs/2139987665
Yeah, sf
is current broken on lots of systems. @edzer and @rsbivand have sent quite a few tweets about it, all related to the epic spatstat
restructure. All are working with CRAN to fix everything asap.
And all may be fixed when Mac binaries are rebuilt hopefully.
Timetable for full alignment in on main spatstat
page. Most packages currently failing (including nearly all of mine) have a grace period until end of March to either auto-align with new system, or to submit updates. March 25th is key date when all on CRAN should be fixed; before then i wouldn't worry too much.
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.