Closed zouharvi closed 2 years ago
I rewrote the tests according to 2&3. Now the cargo test
output looks as follows (second test was intentionally set to fail):
running 2 tests
test test::tests::simple_join ... ok
test test::tests::simple_index ... FAILED
Adding a new test now means adding a function such as this one:
#[test]
fn simple_join() {
test_valid_rjp_output("a.json", "join b.json a,b", "a_join_b_output.json");
}
PS I also removed .json
and .tsv
from gitignore so that I could add the testfiles.
Update: This also allows for some rudimentary testing (once we add larger tests) with cargo bench -- --test
.
Rebased.
One downside of this solution is clutter in tests
.
I think that at some point in the future, we will need to revisit the test structure. One option would be to structure resource files into directories named after individual tests (kind of like the initial approach).
But I don't see an elegant way to do this without repetition, while maintaining that each test is a separate function, so it's easy to see what failed.
Updated the code based on your comments.
I think that at some point in the future, we will need to revisit the test structure. One option would be to structure resource files into directories named after individual tests (kind of like the initial approach).
With the current test code that can still be done. The parameters passed into the test_valid_rjp_output
just need to include the new directory.
I managed to decouple the CLI from the main worker which I now call
main_worker
. There are some issues associated with it that are described intest.rs
, such as the trait bounds etc.Copying the description of the
test_in_dirs
function:Pros of this approach:
Cons of this approach:
cargo test
, all these tests from all folders are under the same nametest_in_dirs
and count as one test.There are three options:
I personally lean towards 3 because it easily fixes all the current cons. What I don't like about it is that the command to run rjp is written in code. From the perspective of tests that seems rather like data and should therefore be in a separate file. But maybe there's an intermediate solution that combines the current directory structure with the more modular functions.
I currently added two test from your comment in #3 and did not think much about their validity. There are more issues with this code, such as panicking whenever rjp panics but I think that for the initial shot on testing it's ok. Apologies it took me so long to get to this.
Let me know whether option 3 is a good way to go and whether you have some more remarks. It should be fairly easy to implement it.