What is needed for 1.0?

[epage]

Collecting feedback or assert_fs. Please post even if you think it might not be needed for 1.0 so we can try to get the big picture of uses, challenges, etc. We're also looking at including experience reports in the 1.0 announcement blog post.

Preferably, please update to the latest version first but don't let upgrading stop you from providing feedback

To help spur feedback, consider these questions

• Why do you use this crate?
• Why don't you use it more?
• How does this crate fit into your testing strategy?
• Is there anything that feels out of place / not rust-like?
• Are there common patterns you implement on top of this crate (e.g. fixture setup or assertions we don't support)?

Also, if your programs deals with the file system, please provide feedback on assert_fs. Even if you don't use it, I want to know why.

---

Summary

Areas to improve

• Improve overview / introduction in README / docs.rs #76 Improve overview / introduction in README / docs.rs
• Highlight Assert::get_output in docs #75 Highlight Assert::get_output in docs
• stdin handling is an unfriendly API #73 stdin handling is an unfriendly API

Successes

fitzgen

assert_cmd is just such a pleasure to use every single time, I fall in love all over again
bravo bravo WG-cli

@passcod

Running commands and dealing with output can be complex in many many ways, so assert_cmd smoothing that is excellent, very much welcome, and improves ergonomics significantly.

@volks73

I have used [assert_cmd] in other projects and I am extremely pleased with it

@coreyja

[assert_cmd] pretty much IS my testing strategy so far, though my app under test is pretty small.

This library has made it really easy to add some test coverage to my project, even when I am just learning how to write Rust!

[epage]

#63 already includes a good heap of feedback

[epage]

@coreyja, @azriel91, @AnderEnder, @dbrgn, @fernandobatels, @mssun, @gnzlbg, @quininer, @zetok: you all have participated in some issues. Could you provide input on this?

[epage]

On Discord, fitzgen made the following comment

assert_cmd is just such a pleasure to use every single time, I fall in love all over again
bravo bravo WG-cli

[passcod]

Running commands and dealing with output can be complex in many many ways, so assert_cmd smoothing that is excellent, very much welcome, and improves ergonomics significantly.

It's not obvious that to get the output of a command without doing asserts on it (e.g. if I want to use another assertion tool) I have to still go through the Assert trait. I ended up writing a helper to read stdout and stderr to string via the Command handle but later saw I could have just used get_output().stdout.to_string()...

For other docs-related things, see my comment on the assert_fs issue as this crate is structured very similarly and suffers from most of the same issues.

Apart from those, good work!

[epage]

From brycx for checkpwn

I am indeed using assert_cmd for a small bit of testing. Though, as you might've noticed, it's a rather small project with very simple tests. On top of that, it's been a long while since I've added tests using assert_cmd and hardly remember the few struggles I've had. That being said:

• I remember switching version (8/9/10?) to 11 was a big change, and for the better. I remember thinking that some of the things I thought weren't as easy to use as they could've been, were improved a lot.

• The first time I used it I had problems with the documentation/examples. I took a quick look just now and it seems to have been improved a lot.

The overall experience for me has been, getting to know the library using roughly two days (4 hours) and then it has basically been a "set-and-forget" situation. So from my standpoint, I'd like it to stay as it is. I hope you can at least get a little out of the sparse feedback here.

Looking forward to the 1.0 release and see what it brings!

[epage]

Thanks @passcod! I've created issues to track your feedback.

[coreyja]

I think I am running into #51 right now in my testing. Here is the code I am working with

let mut cmd = Command::cargo_bin("devicon-lookup").unwrap();
cmd
  .with_stdin()
  .buffer("test.rs".blue().to_string())
  .assert()
  .stdout(format!(" {}\n", "test.rs".blue()).as_str());

Color commands from https://github.com/mackwic/colored

I am also fairly new to Rust, so I am still working on getting my head how lifetimes work, and I also can't comment on how Rust-y the code is!

To answer some of your questions:

How does this crate fit into your testing strategy?

It pretty much IS my testing strategy so far, though my app under test is pretty small. See https://github.com/coreyja/devicon-lookup/blob/master/tests/integration.rs

This library has made it really easy to add some test coverage to my project, even when I am just learning how to write Rust!

[DrSensor]

How does this crate fit into your testing strategy?

Recently I use assert_cmd alongside with rexpect in my REPL program and I love it until I change the implementation to use linefeed.

Are there common patterns you implement on top of this crate (e.g. fixture setup or assertions we don't support)?

Might be a bit out of topic but I would love it if assert_cli has some functionality for assertion in scenario like REPL, Prompt, or anything that involve stdin.
While assert_cmd more focus on CLI that only use stdout/stderr (including sanitize the output a.k.a removing terminal code for color, blinking text, empty line, and others)

[epage]

@volks73

I do not actually use any functionality from the assert_cmd project for cargo-wix. It looks like a hold over from transitioning away from the assert_cli crate and being confused on what functionality was present in which crates. I may have also have added it because I thought I was going to use it, but then did not actually use it. However, I have used it in other projects and I am extremely pleased with it. Usage of assert_cmd lead me to use assert_fs for cargo-wix testing.

[epage]

@coreyja Thanks for the feedback and the comments!

Could you provide the error you are running into? Looking at the code, I actually wonder if you are running into #73.