Closed elbeejay closed 3 years ago
jonschwenk
commented
3 years ago IIRC we used the integration-style tests to cover the unit tests for simplicity/speed of publishing. Definitely better to have the unit tests handled individually. Thanks for taking this on!
elbeejay
commented
3 years ago If IIRC we used the integration-style tests to cover the unit tests for simplicity/speed of publishing. Definitely better to have the unit tests handled individually. Thanks for taking this on!
Yes, this was not a jab at our current implementation, I'm just looking to make the testing suite more comprehensible going forward. :+1:
elbeejay
commented
3 years ago Finishing a truly comprehensive testing suite is probably going to be an on-going project, but I think this PR at the very least splits our true unit tests from the integrative ones. Some of the memory and temporary writing / deleting of directories is eliminated as are the confusing paths at the beginning of the test files.
Don't think I'll be able to tack on many new tests right now, but I plan to branch from this point and start creating actual feature PRs which add core functionality and add to or modify these tests as needed.
jonschwenk
commented
3 years ago Nice work, @elbeejay!
Before proposing changes to the actual substance of RivGraph, I've realized the testing suite needs an overhaul, and this PR will attempt to provide that service. As is, our testing suite mixes "unit" tests of individual functions with "integration"-like tests which test the overall performance of sets of functions against expected results. In the test code itself, we currently use a mess of file paths and create/destroy a set of temporary files each time we run the tests.
It does not have to be this way, and so in this PR we will:
PR is currently a draft as I hope to go through again and separate out the two types of tests, and then write some additional "unit" tests as the majority of our tests are "integration"-style tests.