Add optional access to Command's stdin handle

[volks73]

I was experimenting and I thought I should share some changes based on the discussion in #106.

Key Changes:

• Added the InputPredicate trait to provide access to Command's stdin handle
• Added implementations of the InputPredicate trait to leave public API unchanged and maintain compatibility
• Added doc-tests/examples to the stdin method
• Added the Assert::example constructor (#96)

I also tested these changes with one of my other projects. The non-working example in #106 becomes with this change:

#[test]
fn slow_reply_works() {
    const RESPONSE_TIME: u64 = 10; // seconds
    Assert::example("an_example")
        .stdin("slowReplyMessage")
        .stdin(Wait(RESPONSE_TIME))
        .succeeds()
        .and()
        .stdout().is("expected message")
        .unwrap();
}

where Wait is defined elsewhere and it is a tuple struct that implements the InputPredicate trait.

• [x] I have created tests for any new feature, or added regression tests for bugfixes.
• [x] cargo test succeeds
• [x] Clippy is happy: cargo +nightly clippy succeeds
• [x] Rustfmt is happy: cargo +nightly fmt succeeds

[volks73]

This addresses me not implementing it but I'm still not sure about it

• Seems a bit obscure of a use case

While I agree the origin of this PR and my initial issue submission (#106) is an edge case and somewhat out of the blue with a more common usage to read stdin as a block data in one shot, like from file redirection, streaming data to and from a CLI application via pipes is a common practice. The current API, and after an admittedly quick review of the forthcoming new API (#98), only supports writing single blocks of data to a CLI application, yet stdin is a stream where data can be written to it over time. I thought these changes would be a nice way to extend functionality to test the streaming nature of stdin if needed while still maintaining the simplicity and elegance that makes this crate attractive for testing CLI applications.

• Contemplating how well it will fit with the new API. Ideally we'll have that in by the end of the month.

If the new API is intended to be a toolkit for creating CLI test frameworks, then I would appreciate some way to test the stream nature of stdin in the new API and/or supply a mechanism to expose the stdin handle from Command. I would be happy to spend some time on investigating this for the new API.

In general, this use case seems better served by a command/response approach.

Can you expand on this a little more? I do not know what you are referring to. I was under the impression that the current API for this crate is a command/response approach.

Maybe StdinWriter?

This is more descriptive of its usage and works for me.

[epage]

Could you look at https://github.com/assert-rs/assert_cmd and see how this new API works for your needs?

Note: assert_cmd is basically what assert_cli is today. I think killercup wants to take assert_cli and turn it into a higher level, more opinionated crate.

[volks73]

Could you look at https://github.com/assert-rs/assert_cmd and see how this new API works for your needs?

Yes. I will take a look, thank you.