|
| 1 | +# covidcast development guide |
| 2 | + |
| 3 | +A short checklist for submitting pull requests: |
| 4 | + |
| 5 | +1. Run the unit tests with `devtools::test()` and ensure they pass. |
| 6 | +2. If you have added any new features (new functions, new options, etc.), add a |
| 7 | + brief description to `NEWS.md` to the next listed version number. Also ensure |
| 8 | + that new functions or datasets are listed in the reference in `_pkgdown.yml` |
| 9 | + so they appear in a good place in the documentation website. |
| 10 | +3. If you changed any documentation, rebuild the documentation with |
| 11 | + `devtools::document()` and then `pkgdown::build_site()`. (This can be slow, |
| 12 | + because our vignettes take a long time to build.) |
| 13 | +4. Submit the pull request and see if the CI can also successfully run the |
| 14 | + tests. |
| 15 | + |
| 16 | +## Unit tests |
| 17 | + |
| 18 | +Unit tests are provided in `tests/testthat/` and use the [testthat |
| 19 | +package](https://testthat.r-lib.org/). Tests are automatically run as part of `R |
| 20 | +CMD check`, but during package development, the easiest way to run all tests is |
| 21 | +via `devtools::test()` from within the package working directory. |
| 22 | + |
| 23 | +Our continuous integration (CI) on GitHub will automatically run the unit tests |
| 24 | +when you open a pull request, as part of running `R CMD check`. Failed tests and |
| 25 | +check errors will both result in the build failing and errors being visible in |
| 26 | +the pull request. |
| 27 | + |
| 28 | +### Testing plots |
| 29 | + |
| 30 | +We test our plots and maps with the [vdiffr](https://github.com/r-lib/vdiffr) |
| 31 | +package, which renders plots and then visually compares them to a saved |
| 32 | +reference image. |
| 33 | + |
| 34 | +See `tests/testthat/test-plot.R` for examples. Each test case uses |
| 35 | +`vdiffr::expect_doppelganger` with two arguments: a name (which will be the |
| 36 | +filename of the saved plot, so ensure this is descriptive and unique) and a |
| 37 | +plot, such as a ggplot object. |
| 38 | + |
| 39 | +When you add new test case or change how a plotting feature works, you will need |
| 40 | +to "validate" the tests, meaning vdiffr will render the plots and ask you if |
| 41 | +they look correct. To do this, run `vdiffr::manage_cases()` from within the |
| 42 | +package working directory. A Shiny app will open up and present you with each |
| 43 | +plot. For new plots, it will simply show you the plot, and a "Validate" button |
| 44 | +will let you indicate that the plot looks good. For changed plots, it will show |
| 45 | +you the difference between the saved image and the new plot. You must ensure |
| 46 | +that the changes look correct, then press Validate. |
| 47 | + |
| 48 | +Once you've validated all changes, press Quit and you will be able to commit the |
| 49 | +changed images and run the tests successfully. |
| 50 | + |
| 51 | +### Using data files in tests |
| 52 | + |
| 53 | +Unit tests should not depend on being able to load data from the COVIDcast API, |
| 54 | +since that data is subject to change. It is preferable to either use toy |
| 55 | +examples or to store static datasets to be loaded and used. |
| 56 | + |
| 57 | +Small static datasets can be kept in `tests/testthat/data/` in RDS form (using |
| 58 | +`saveRDS` and `loadRDS`). The `testthat::test_path` function locates files |
| 59 | +relative to the `tests/testthat/` directory regardless of your current working |
| 60 | +directory, so for example you can use |
| 61 | + |
| 62 | +```r |
| 63 | +foo <- readRDS(test_path("data/foo.rds")) |
| 64 | +``` |
| 65 | + |
| 66 | +to load `tests/testthat/data/foo.rds`. |
| 67 | + |
| 68 | +## Documentation |
| 69 | + |
| 70 | +We use |
| 71 | +[roxygen2](https://cran.r-project.org/web/packages/roxygen2/vignettes/roxygen2.html) |
| 72 | +and [pkgdown](https://pkgdown.r-lib.org/index.html) to build good-looking |
| 73 | +documentation automatically. We should strive to have clear documentation for |
| 74 | +all exported functions and data, as well as vignettes giving examples of all |
| 75 | +major package features. |
| 76 | + |
| 77 | +After changing a vignette or documentation, you'll need to rebuild the |
| 78 | +documentation. Use `devtools::document()` to do this. Then |
| 79 | +`pkgdown::build_site(".")` (from within the package directory) will rebuild the |
| 80 | +HTML documentation site. |
0 commit comments