Open gorcha opened 3 years ago
Great idea!
In terms of parsing the test results, do you have in mind adding some indication of test success/failure to the visualisation? For instance, using dark red for sources/recipes associated with failures?
That'd be cool! I wonder if you could use a javascript library for the vis so you could make it a linkable graph, and hotlink recipes to their test results? Not exactly the same thing but kind of like how covr gives you a little temporary html doc to go through your test coverage. For e.g. vis.js (haven't actually used it, just first search result :P)
I've been reading a bit about the validate package as well, which could be cool. It's a tiny bit more restrictive than what you can do with for e.g. testdat but there are some really cool features like specifying validation sets from yaml - check out the section in the docs
I wonder if you could even do both, like a "test" argument that allows you to specify a test set for the recipe, and a "validate" argument that lets you provide validation rules for each of the targets?
I'm actually using the visNetwork package under the hood, which is just a wrapper for vis.js, so I reckon there would be a way to get the linking to work. But might be difficult to actually get the test results in an html format.
That validate package looks cool. I love the yaml specification of test rules. I kinda wanna look at doing something similar for testdat now...
I reckon sticking with the generic testthat
framework would be better though, since I want to make as few assumptions about what users are going to be doing in their pipelines as possible.
It'd be cool to have a test argument to the make functions that can either be an expression or a file/directory path, that is run at the end to validate the make.
Depending on the type:
test_dir()
ortest_file()
as appropriateWould need to think about how to parse test results while also allowing maximum flexibility, since different testing approaches would return different things (e.g. test_dir/test_file return the test results, an expression block with a test_that call in it would return either NULL or throw an error).
For e.g.