consider documenting input data and/or making mock input data

[cjyetman]

No description provided.

[jdhoffa]

I wanted to add some of my thoughts here from my experience with r2dii:

I think that it is important to keep the concepts of unit-testing and CI/CD separate (but related) here. Some type of representative data is useful for all of those use-cases, in different capacities. Below are some thoughts:

Unit testing

• Having unit tests that depend on an external package has been a huge pain in the ass for me so far (see upkeep: don't depend on r2dii.data for unit tests r2dii.match#392 and upkeep: Don't depend on r2dii.data for unit tests r2dii.analysis#472). Unit tests should be self-sufficient, the point of them is to test specifically the functionality of the functions that are in the package in question. The point of the unit test is/ has never been to ensure that the package integrates well in a broader ecosystem
• so for that use-case, I think it makes sense to have simple mock input data, that highlights particular behaviours, or data that has triggered particular bugs in the past, with clear tests to ensure they don't pop back up (for this use-case, for me, this type of thing has proved hugely useful: https://github.com/RMI-PACTA/r2dii.analysis/blob/main/tests/testthat/helper-fake_data.R)

CI/CD

• With CI/CD, we are trying to prove, in an automated way, that the whole ecosystem WORKS
• The work @AlexAxthelm has done with GH actions and Azure, running the whole shebang using the REAL azure data, does a frankly awesome job of this, and is probably sufficient there for now (though I'm sure being able to do it also in a public way is useful
• If we want to do this using "mock data" (which would then simultaneously serve the purpose of documentation), then I think THAT mock data should live in an external package (e.g. https://github.com/RMI-PACTA/pacta.demo.data) that serves to mock ALL inputs, and that the CI/CD system can easily pick up and run the whole process