ripytide
commented
6 months ago In my experience testing is very specific to the project, algorithm heavy code favors unit and property testing since functions tend to be pure and deterministic. Libraries like this however, tend to be better suited to integration tests since they are mainly for interacting with external systems like all the different package managers.
I think the best tests I could imagine would be full end-to-end tests in which we run pacdef on a test machine and go through a set of pacdef commands asserting that the test machine has the expected packages at each stage through the process.
In terms of frameworks/crates for testing, I'm not entirely sure since I've never done any end-to-end tests for rust before as my projects tend to be more algorithmic and I'd usually use proptest. The rust docs for integration testing might be a good place to start though. Running the tests in a docker container might also be valuable for this for setting up a machine the same way everytime for the running the tests github action + docker.
Other than that, I think simply being a responsive maintainer and fixing any bug reports in a timely fashion from testing in production is a pretty good methodology too :smile:
steven-omaha
@ripytide thank you for all the excellent work you have put in pacdef over the past weeks. This has really helped with the quality of the code and got rid of some long standing quality issues.
I would like to add more tests to this project. The last PR #77 that almost introduced a bug (which I only caught by accident and manual testing before merging) highlighted that tests are definitely needed to not break things unexpectedly.
You seem to be very experienced and knowledgeable in Rust, definitely more so than me. I'm looking for your advice here first of all: