pbchase
commented
2 months ago The commits in this PR are the first of many. I'll admit I might merge this and release it because I want to see the documentation changes reflected in the public documentation website.
I am resisting the urge to merge and deploy this. Feel free to review it and understand it.
saipavan10-git
@saipavan10-git, I started a project last night to move test functions and test data into the
./tests/testthat/space. The commits in this PR are the first of many. I'll admit I might merge this and release it because I want to see the documentation changes reflected in the public documentation website. Yet I want you to see what I am doing. It's a multi-pronged effort to reduce the scope of what is documented so you and others are not distracted by test code and test data. The changes come in a few forms:Testing helpers
I moved several testing helper functions from
R/devtools.Rtotests/testthat/helper-package-specific.R. Files that match the patterntests/testthat/helper*.Rare executed before running tests. It makes the functions available to tests and only tests.Moving the functions makes their man pages disappear from
./man/Moving test data
We generated a lot of test data with code in
./data-raw/, writing the test data to./data/, and documenting it with Roxygen2 code in./R/data.R. All that was the wrong approach. To fix that, I am making these changes:./data/foo_test_data.rd?to./tests/testthat/foo/test_data.rd?or./tests/testthat/foo/foo_test_data.rd?./data-raw/foo_test_data.Rto./tests/testthat/foo/make_test_data.R. In the same stroke, I change the place wheremake_test_data.Rwrites its output../R/data.R. That deletion makes their man pages disappear from./man/Replacing SQLite3 with DuckDB
In older tests, we use in-memory SQLite3 databases to house test data when tests need to run a function that connects to a DB. This was a poor choice because the SQLite3 data types are so limited. The lack of a proper datetime format is a big issue. In modern tests, we use a DuckDB in-memory database for its richer datatype support. In these commits, I am replacing SQLite use with Duck DB.
Streamlined table creation
In the older tests, we would create a table from a schema file, then populate the table from a test dataset. In newer tests, we create and populate tables in one step by reading a dataframe of test data, then calling with
DBI::dbWriteTable()with the data frame as thevalueoption toDBI::dbWriteTable()Stop testing Schema files
We have a few tests of schema files to verify they load correctly. They are hacky, nearly useless, and a pain to rework for DuckDB. I am deleting these tests.
Other stuff
I have had to make a few small tweaks to functions and tests that broke with DuckDB, but they are few in number and small in size.