Write formal unit tests using testthat

[jsocolar]

Unit tests should cover all reasonable combinations of input arguments, where applicable should cover both rep-constant and rep-varying models, and where applicable should cover both ragged and non-ragged input data.

Tests that require fitting models should use very low iteration numbers with fixed seeds to verify behavior. However, prior to writing such tests the author should fiddle around with the behavior being tested enough to verify that it seems to be doing the right thing. Full SBC is not necessary, but reasonable parameter recovery (or posterior prediction, or loo comparisons or...) should be verified for multiple models prior to writing the compute-efficient tests. It's important to keep these tests compute-efficient so we can continue to run R cmd check on Github for free.

The highest priority functions for unit testing are the following. Once we have reasonably good tests written for these, I'll go ahead and close, bump the version number, and open a new low-priority issue for unit testing the remainder of the functions in flocker, including non-exported functions.

Edited to remove checklist which is no longer particularly relevant to the package structure.

[jsocolar]

I've made a start on this with unit tests for make_flocker_data. More to come.

[jsocolar]

We are now passing R cmd check on Github Actions. Let's work on getting an Rstan backend up and running, and then finishing the unit tests so that we can forestall a huge amount of work to get CRAN ready in the distant future.

[jsocolar]

@SimonCMills FYI I'm working through unit tests for the utils on the utils-tests branch. If you have time for unit testing this weekend, focus on something other than the utils.

[jsocolar]

closed via a series of pulls ending with https://github.com/jsocolar/flocker/pull/95