Reuse output assertions between stdout/stderr #38
Conversation
BREAKING CHANGE: Setting a new output assertion will not overwrite the previous one.
This simplifies the logic for generically adding new assertions at the cost of an match statement for each output assertion executed.
BREAKING CHANGE: - `.prints` -> `.stdout().contains` - `.prints_exactly` -> `.stdout().is` - `.prints_error` -> `.stderr().contains` - `.prints_error_exactly` -> `.stderr().is`
|
From #36
Understandable. #35 was an intermediate step and so my full intent of where I was going with this wasn't clear. Now that I have the rest of the changes (though possibly controversial?), it should help. Feel free to tell me you don't like bits and I'll pull out the commits you do like and get a PR up for those. With the full, new API, any thoughts on communicating that these append instead of replace? My original thought was more along the lines of a general fluent API rather than specifically a fluent builder and didn't consider the possible confusion that this might provide. |
|
@killercup this now has documentation/test for the new multiple-output-assertions behavior. While I admit
#[macro_use] extern crate assert_cli;
fn main() {
assert_cmd!(echo "Hello world! The ansswer is 42.")
.stdout().contains("Hello world")
.stdout().contains("42")
.stderr().is("")
.unwrap();
}
Thanks! |
| &o.stderr | ||
| pub fn map_err(self, e: Error, cmd: &[String]) -> super::errors::Error { | ||
| match self { | ||
| OutputKind::StdOut => super::errors::ErrorKind::StdoutMismatch(cmd.to_vec(), e).into(), |
There was a problem hiding this comment.
I'd use super::errors::ErrorKind::*; but doesn't really matter :)
There was a problem hiding this comment.
Thanks for the idea. I was unsure what could be used to simplify it without mixing up the file's error chain with the crate's error chain.
38: Reuse output assertions between stdout/stderr r=killercup a=epage Reusing output assertions makes it easier to add new ones in the future. I feel the new naming scheme this provides makes intent of the API clearer as well (`stdout().contains` vs `prints`). This is done by creating an `OutputAssertionBuilder` that `Assertion` delegates to for creating output assertions, passing in an enum of which stream to read from. This unfortunately meant dropping the cool type tricks that were introduced in #24. This also required merging the storage of stdout/stderr assertions. To accommodate this, output assertions are now appended which might be useful on its own.
|
And for making a release: I've added you as owner to the crate on crates.io :) Feel free to make a PR with a version bump/changelog and release this as 0.5! :) |
Build succeeded |
Reusing output assertions makes it easier to add new ones in the future.
I feel the new naming scheme this provides makes intent of the API clearer as well (
stdout().containsvsprints).This is done by creating an
OutputAssertionBuilderthatAssertiondelegates to for creating output assertions, passing in an enum of which stream to read from. This unfortunately meant dropping the cool type tricks that were introduced in #24. This also required merging the storage of stdout/stderr assertions. To accommodate this, output assertions are now appended which might be useful on its own.