tests(turbo): Rust CLI Tests #2379
Conversation
|
@NicholasLYang is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 5 Ignored Deployments
|
| ..Args::default() | ||
| }, | ||
| } | ||
| .test(); |
There was a problem hiding this comment.
nit: is it convention to put all rust tests in the same file (as opposed to .test.rs or something? Feels pretty noisy/distracting to have this here
There was a problem hiding this comment.
I see shim/tests/mod.rs. What's the difference between those tests and these?
There was a problem hiding this comment.
It's a difference of integration versus unit tests. These are tests that require internal data structures like Args that we wouldn't have access to in tests/. I agree that this file is starting to get unwieldy though. Might split it up and put the repo state code in its own file.
|
Also, do we need a GH workflow to run these tests or does that already exist somewhere? |
| @@ -1,5 +1,69 @@ | |||
| use assert_cmd::Command; | |||
|
|
|||
| static TURBO_HELP: &str = "turbo | |||
There was a problem hiding this comment.
Commented on #2386, but I generally prefer to keep UI snapshot tests in something like cram/prysk that has better support for updating snapshots support for diffing snapshots.
| } | ||
| } | ||
|
|
||
| fn create_all_arg_permutations(&self) -> Vec<Vec<&'static str>> { |
There was a problem hiding this comment.
Should we also be testing interspersing global args with the command args? If I'm reading this correctly we're only putting global args right after turbo. IIRC correctly cobra allows for these args to appear anywhere which is a behavior we want to keep.
There was a problem hiding this comment.
So the algorithm tests all permutations of the global args with the command, so for [[ "login" ], [ "--cwd ../example/basic"]] it tests:
[[ "login" ], [ "--cwd ../example/basic"]]
[[ "--cwd ../example/basic"], [ "login" ]]
I added the command for the global arg permutations for the exact reason you stated; this lets us test the global arguments both before and after the subcommand. It does however mean that we only place sub-command arguments after the global arguments, but I think that's good enough.
c3acfe4 to
59be635
Compare
Adding tests for both CLI parsing and e2e.