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

Tests #18

Closed
3 tasks
Robinlovelace opened this issue Nov 9, 2020 · 9 comments
Closed
3 tasks

Tests #18

Robinlovelace opened this issue Nov 9, 2020 · 9 comments

Comments

@Robinlovelace
Copy link
Member

Robinlovelace commented Nov 9, 2020

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.

Robinlovelace added a commit that referenced this issue Nov 9, 2020
@Robinlovelace
Copy link
Member Author

Exciting update, after the commit above, we're now on 5%, 70 more percentage points to go!

image

@layik
Copy link
Member

layik commented Nov 10, 2020

👍

@Robinlovelace Robinlovelace mentioned this issue Jan 26, 2021
@mpadge
Copy link
Member

mpadge commented Feb 8, 2021

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.

@Robinlovelace
Copy link
Member Author

Finally taking a looking at this.

Robinlovelace added a commit that referenced this issue Mar 18, 2021
Robinlovelace added a commit that referenced this issue Mar 18, 2021
@Robinlovelace
Copy link
Member Author

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...

@Robinlovelace
Copy link
Member Author

E.g.: failing tests on osmdata https://github.com/ropensci/osmdata/runs/2139987665

@mpadge
Copy link
Member

mpadge commented Mar 19, 2021

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.

@Robinlovelace
Copy link
Member Author

And all may be fixed when Mac binaries are rebuilt hopefully.

@mpadge
Copy link
Member

mpadge commented Mar 19, 2021

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.

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

3 participants