rspec/rspec-expectations — pull request #410 by lucapette (2014-01-05 22:23:25+00:00)
Title: OutputToStdout and OutputToStderr matchers

This pull-request is a very raw draft of how I would like to implement two new built-in matchers that have been discussed in #399, since @matthias-guenther said he wouldn't have the time to move on with it I thought it would have been great to try to contribute to my favourite Ruby open-source project.

What I did so far is implementing the matchers following the specs suggested by @myronmarston to a point all the specs I have are green on MRI 2.1.0 (not sure about other implementations but travis-ci will answer this question soon).

Since it's the first time I try to contribute to RSpec please bare with me because I have some questions:

- If I understood it correctly we need alias methods (and tests for them) for `output_to_stdout` and `output_to_stderr` like `output_from_stdout` in order to support composition of the matchers.

- We need cukes because all the matchers have them, for documentation reasons if I understood it.

- I'm not sure you like the fact we have one `OutputToStream` class handling both `$stdout` and `stderr`. I did it in order to fight a clear duplication. What I don't like about this approach is the way we find out which stream is requested (`@stream == $stdout` for example).

- I can't say I like the naming of all the things. But this is a problem I always have, I'm never satisfied with names. Never. It's always a trade-off for me and I'd like to know if you like the one we currently have.

- In the current implementation we have the shared examples for both matchers in the existing file we have for a more general shared example. I can live with this but I can't say if it's OK with you.

- A problem connected with the previous is that now we have two different spec files for the matchers but we have one file (with a different name) with the actual implementation.

- I think we're covering all the basic cases but since it's the first time I'm trying to test a testing framework (that's so nicely meta btw) that I can't say the coverage we have it's enough. I added some tests to the one suggests in #399 and changed the wording a bit.

Sorry for asking so many questions :)