How to test Ruby methods that involve puts or gets

by Jason Swett,

I recently saw a post on Reddit where the OP asked how to test a method which involved puts and gets. The example the OP posted looked like the following (which I’ve edited very slightly for clarity):

What makes the ask_for_number method challenging to test is a dependency. Most methods can be tested by saying, “When I pass in argument X, I expect return value Y.” This one isn’t so straightforward though. This is more like “When the user sees output X and then enters value V, expect subsequent output O.”

Instead of accepting arguments, this method gets its value from user input. And instead of necessarily returning a value, this method sometimes simply outputs more text.

How can we give this method the values it needs, and how can we observe the way the method behaves when we give it these values?

A solution using dependency injection (thanks to Myron Marston)

Originally, I had written my own solution to this problem, but then Myron Marson, co-author of Effective Testing with RSpec 3, supplied an answer of his own which was a lot better than mine. Here it is.

I comment on this solution some more below, but you can see in the initialize method that the input/output dependencies are being injected into the class. By default, we use $stdin/$stdout, and under test, we use something else for easier testability.

Under test, an instance of StringIO can be used instead of $stdout, thus making the messages sent to @output visible and testable. That’s how we can “see inside” the Example class and test what at first glance appears to be a difficult-to-test piece of code.

  • 2

5 thoughts on “How to test Ruby methods that involve puts or gets

  1. Myron Marston

    This is what I’d do instead:

    We talk about this a fair bit in Effective Testing with RSpec 3, but any code that does I/O is going to be far better off being tested with StringIO instead of mocking the _exact method calls_ producing the output. puts "a"; puts "b" and puts "a\nb" behave _identically_, but you can’t write a test that mocks puts that would pass for both implementations, which is a problem. StringIO avoids this; it allows you to test what output was produced, without specifying _how_ the output was produced.

    Going this route improves the design of the Example class, too:

    * It clearly documents its dependencies in its initializer (previously they were implicit)
    * Callers are able to control where the object gets its input from and writes its output to

    1. Jason Swett Post author

      Hey Myron, thanks for sharing this. I like your approach a lot better than mine. Would it be okay if I update my post to include your version (with full credit of course)?

  2. Deen

    Loved the article, Jason. I have a question that might be slightly outside this article’s scope, but it seems odd to me that an rspec it block testing for failure needs this passing test at the end to break the loop and return the test results to the CLI:

    expect(subject).to receive(:gets).and_return(6)
    expect(subject.ask_for_number).to be true

    I’ve tried replacing those 2 lines with just subject.ask_for_number but it freezes at the third test due to the loop. Is there another way to do this?


Leave a Reply to Jason Swett Cancel reply

Your email address will not be published. Required fields are marked *