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