-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
test(cli): Track --help output #11912
Conversation
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
7e5a07b
to
e5b9f23
Compare
I'm a little concerned that this introduces two modules for almost every command, and it may not be clear how to manage tests with that structure. That is, there is a |
@@ -0,0 +1,12 @@ | |||
use cargo_test_support::curr_dir; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, is there a reason curr_dir
is not in cargo_test_support::prelude
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. I can add it if wanted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might help with some of the boilerplate. It looks like it is used for essentially every UI test. This is unrelated to this PR, though, and can be done any time.
I had originally wanted to punt on |
If you want to defer on figuring out the module structure, would it be possible to just add the tests to the existing modules in the mean time? I assume I would prefer to avoid moving forward with something that puts it in an incomplete state without some idea or strategy for where it is intended to end up. |
This does not get us out of being in an inconsistent, intermediate state since this would then make the UI tests inconsistent with each other. Since those all follow a very similar pattern, I would like to keep them as such for easily modifying them in the future.
Except thats what software evolution is, is to always be in some kind of incomplete state as you work towards your ideal. To take a stance you can't improve anything until everything is improved leaves you always in a worse place than small, incremental progress. This was meant to be the simple, quick PR to unblock other help work. I feel like these discussions are already exceeding a reasonable time box for that scope but stalls out future improvements in other areas. |
☔ The latest upstream changes (presumably #12069) made this pull request unmergeable. Please resolve the merge conflicts. |
This is split out of rust-lang#11912 and is prep for adding more UI tests. Generally our UI tests are in a directory named after the full cargo command (`cargo config`). These tend to use `snapbox`. Here we are tests for the `cargo config` command not written by `snapbox` in a `cargo_config.rs` file. This conflicts with adding snapbox UI tests later in a `cargo_config/` folder. Upon looking at this file, it appears to be UI tests, so I think it would make sense to move them into the `cargo_config/` folder. Definitely wouldn't make sense to move them into `config.rs` since that is general config testing.
This is split out of rust-lang#11912 and is prep for adding more UI tests. Generally our UI tests are in a directory named after the full cargo command (`cargo config`). These tend to use `snapbox`. Here we are tests for the `cargo config` command not written by `snapbox` in a `cargo_config.rs` file. This conflicts with adding snapbox UI tests later in a `cargo_config/` folder. Upon looking at this file, it appears to be UI tests, so I think it would make sense to move them into the `cargo_config/` folder. Definitely wouldn't make sense to move them into `config.rs` since that is general config testing.
refactor(test): Move cargo-config into a dir This is split out of #11912 and is prep for adding more UI tests. Generally our UI tests are in a directory named after the full cargo command (`cargo config`). These tend to use `snapbox`. Here we are tests for the `cargo config` command not written by `snapbox` in a `cargo_config.rs` file. This conflicts with adding snapbox UI tests later in a `cargo_config/` folder. Upon looking at this file, it appears to be UI tests, so I think it would make sense to move them into the `cargo_config/` folder. Definitely wouldn't make sense to move them into `config.rs` since that is general config testing.
This makes it easier to evaluate the usability of PRs, like rust-lang#11905
Discussion on test organization has moved to https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Brainstorming.20on.20test.20organization with the consent of @ehuss |
☀️ Test successful - checks-actions |
Update cargo 14 commits in 7ac9416d82cd4fc5e707c9ec3574d22dff6466e5..c91a693e7977e33a1064b63a5daf5fb689f01651 2023-07-24 14:29:38 +0000 to 2023-07-31 00:26:46 +0000 - fix: align `cargo --help` text (rust-lang/cargo#12418) - fix: normalize relative git submodule urls with `ssh://` (rust-lang/cargo#12411) - test: relax help text assertion (rust-lang/cargo#12416) - test: relax assertions of panic handler message format (rust-lang/cargo#12413) - fix(package): Recognize and normalize `cargo.toml` (rust-lang/cargo#12399) - Clarify `lto` setting passing `-Clinker-plugin-lto` (rust-lang/cargo#12407) - doc: add missing reference to `CARGO_PROFILE_<name>_STRIP` in environment variables docs (rust-lang/cargo#12408) - Update curl-sys to pull in curl 8.2.1 (rust-lang/cargo#12406) - docs: raise awareness of resolver used inside workspace (rust-lang/cargo#12388) - chore: update `home` to 0.5.7 (rust-lang/cargo#12401) - Update curl-sys to pull in curl 8.2.0 (rust-lang/cargo#12400) - test(cli): Track --help output (rust-lang/cargo#11912) - refactor(test): Move cargo-config into a dir (rust-lang/cargo#12398) - refactor(tests): Name init ui tests more consistently (rust-lang/cargo#12397) r? `@ghost`
What does this PR try to resolve?
This makes it easier to evaluate the usability of PRs, like #11905
This follows the pattern of
cargo add
andcargo remove
of putting these ui tests incargo_<cmd>/
directories.init
didn't follow this pattern, so it was renamed tocargo_init/
.cargo_config.rs
was going to conflict with this, it was merged in.We can evaluate other
<cmd>.rs
files at a later point and consolidate.How should we test and review this PR?
The main risks are
main.rs
-><cmd>/mod.rs
-><cmd>/<help>.rs
help/mod.rs
s pointing to the right command