-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make tests first-class citizens #723
Comments
I just found cargo-xtask which describes itself as a The rust-analyzer project uses it to generate data structs and tests. |
There's been some stride to get this done. The current open PRs & issues cover most of the integrations test organizing. What's left is to actually improve the integration testing (possibly with more elaborate tests). That should be a separate issue. The other set of items that are left is the model-based testing but Andrey and Shivani have a lot on their plate to get that done. Most probably that will also go into another issue. Thane's idea of using |
We identified four different kinds of tests in a discussion with Thane:
cargo test
.Note: the Rust book defines integration tests as tests among different public-facing components of the Rust code. We enhance this interpretation with "testing different components of the ecosystem against the public-facing components of the Rust code".
We would like both our CI and local dev runs to have an easy method to run all these tests. Additionally, it would be nice to make sure that maintaining these environments are easy too. At last, we want to make sure that the results of these tests are easy to troubleshoot.
The current method is to run
cargo test --all
for the regular tests and run the ignored testscargo test -- --ignored
for the Tendermint-Go integration tests. The problem with this approach is that it can't be made more granular: the gaiad endpoint would require an--ignored2
option while we might want to exclude the model-based tests in some cases.Someone mentioned the option of moving tests into separate config features.
The model-based tests take the approach of pinpointing a group of tests with the
--tests
switch.Thane also mentioned using cargo-make as an option to unite the testing methods. Shiplift also came up as an option to manage Docker executions. Earthly.dev also came up as a way of merging Makefiles, Dockerfiles and Bash scripts into a more manageable format.
We should discuss and make a plan so we can start organizing our tests better and implement these additional features.
The text was updated successfully, but these errors were encountered: