Fluent Output Tests Look off with rustfmt

[epage]

The API looks weird when run through rustfmt because it puts each function on a separate line, so it clouds up what the predicate is operating on

• Keep it, tools are meant to work for us
• Go back to having a function per variant
• Follow Environment and take in a predicate parameter
  • Easier to do multiple predicates (option to take in an array)
  • While it helps in places, I found it annoying in clap to access a bunch of different types
  • More linking is needed to help people find all of the relevant predicates

(Split of from #41)

[epage]

RE Accepting predicates (from #41)

One thing in favor of accepting predicates as parameters is that someone wanted to pass multiple predicates at once which is more of an issue with contains and negated contains/is and not is.

But! At that point me might as well do .stderr(|x: OutputAssertThingy| -> bool { x.is("bar") || (x.contains("baz") || !x.is("bazinga")) }) to not reinvent boolean expressions. Which I think was something someone was asking for in another issue anyway (cf. #57).

I think there is still value in specialized predicates for better error reporting. We could just use From to auto-convert a Fn into one of the predicates.

[killercup]

Error reporting is a good point! We should aim for nice errors, as that is what people are using the crate for.

I didn't specify what OutputAssertThingy is in that quote… so maybe we can try to write a type that overloads boolean operators in a very clever way?

[epage]

In addition to the existing PR exploring this, #98 would also possibly resolve this.

[epage]

Addressed in assert_cmd
https://github.com/assert-rs/assert_cmd
assert_cli is going to morph into a wider-focused tool, including things like assert_fs. See #41