These are some non-code suggestions.
cargo-release
This is the most popular crate for releasing/publishing crates. It handles all the the common tasks for you, including pre-populating the CHANGELOG (can be manually intervened). See: https://github.com/crate-ci/cargo-release
Actix integration tests
Actix has some nice bundled tooling to easily test HTTP requests and responses: https://actix.rs/docs/testing
Preferring mod.rs module definitions
I admit I have no good argument for adopting this convention. Other than it's more common. I just prefer it. I don't think it's a big deal. Maybe an argument could be that self-named modules are harder to "read", which may introduce an unnecessary moment of confusion for newcomers that will be more used to seeing mod.rs examples in all the docs.
Build the sample Library Git repo for each test run
This isn't actually a Rustism, just feedback from somebody reading the code. Basically I just want to know what's actually in that bare repo, like what files, what its folder structure is, etc. Without knowing that, the tests aren't so useful as documentation, all I know is when they pass and fail, not so much about the actual behaviour they are ensuring. Gitoxide actually builds repos from scratch in their test suite, so it's certainly feasible, see: https://github.com/Byron/gitoxide/blob/main/git-repository/tests/fixtures/make_basic_repo.sh
These are some non-code suggestions.
cargo-releaseThis is the most popular crate for releasing/publishing crates. It handles all the the common tasks for you, including pre-populating the CHANGELOG (can be manually intervened). See: https://github.com/crate-ci/cargo-release
Actix integration tests
Actix has some nice bundled tooling to easily test HTTP requests and responses: https://actix.rs/docs/testing
Preferring
mod.rsmodule definitionsI admit I have no good argument for adopting this convention. Other than it's more common. I just prefer it. I don't think it's a big deal. Maybe an argument could be that self-named modules are harder to "read", which may introduce an unnecessary moment of confusion for newcomers that will be more used to seeing
mod.rsexamples in all the docs.Build the sample Library Git repo for each test run
This isn't actually a Rustism, just feedback from somebody reading the code. Basically I just want to know what's actually in that bare repo, like what files, what its folder structure is, etc. Without knowing that, the tests aren't so useful as documentation, all I know is when they pass and fail, not so much about the actual behaviour they are ensuring. Gitoxide actually builds repos from scratch in their test suite, so it's certainly feasible, see: https://github.com/Byron/gitoxide/blob/main/git-repository/tests/fixtures/make_basic_repo.sh