Can you control $stdout when specs are running?

Hi all,

I’m testing java classed using rspec and jruby. The java super class
is trapping an exception and sending a custom message to stdout along
with the original exception meaasage. The original exception is a
SAXParseException, if that really matters. Well, my test is to see if
the child object class can handle a garbled XML message a certain
way. The test passes, but I get the nasty java exception stuff that
is being sent to stdout when the tests are running, yuk. I tried
closing and opening stdout before and after that particular test and
that did not work or I did it wrong. And I’m not sure this is
desirable if the test fails. Any ideas on this other than to replace
the java with ruby or have the java not to dump to stdout? :wink: Both
of which, I can not do. But, I can live with the nastiness of this,
if there is no possible way around it.

Thanks,

GregD

On Sep 30, 2010, at 10:06 AM, GregD wrote:

that did not work or I did it wrong. And I’m not sure this is
desirable if the test fails. Any ideas on this other than to replace
the java with ruby or have the java not to dump to stdout? :wink: Both
of which, I can not do. But, I can live with the nastiness of this,
if there is no possible way around it.

I’d like to bump this message because I am facing a similar situation.

What’s a good technique for spec’ing code that prints to STDOUT yet
keeps the spec output nice and clean?

cr

Excerpts from Chuck R.'s message of Wed Jan 12 07:52:58 -0800 2011:

I’d like to bump this message because I am facing a similar situation.

What’s a good technique for spec’ing code that prints to STDOUT yet keeps the
spec output nice and clean?

I can’t promise that what follows is a “good” technique for this, but it
works
for me. At the moment, I can’t quite recall why this doesn’t get in the
way of
rspec’s own output.

The stuff outside of the configure block is not strictly necessary, but
helpful
if you want to be able to debug specs without the output of ruby-debug
being
sent to your buffers.

spec/spec_helper.rb

Rspec.configure do |c|
# capture output
@output = ‘’
@err = ‘’
$stdout.stub!( :write ) { |*args| @output.<<( *args )}
$stderr.stub!( :write ) { |*args| @err.<<( *args )}
end

Track original $stdout, $stderr write methods so we can restore them

for

debugging

class << $stdout
alias_method :real_write, :write
end
class << $stderr
alias_method :real_write, :write
end

class Object
def debug
# For debugging, restore stubbed write
class << $stdout
alias_method :write, :real_write
end
class << $stderr
alias_method :write, :real_write
end

  require 'ruby-debug'
  debugger
end

end

Why not stub System.out.println, possibly with message expectations if
necessary?

On Jan 12, 2011, at 9:52 AM, Chuck R. wrote:

way. The test passes, but I get the nasty java exception stuff that
What’s a good technique for spec’ing code that prints to STDOUT yet keeps the
spec output nice and clean?
I prefer to avoid printing directly to STDOUT, and pass in an IO object
to the constructor of the object doing the printing.

class Foo
def initialize(output=$stdout)
@output = output
end

def do_something_that_prints
@output.puts “blah, de blah”
end
end

Now implementation code can just use a Foo.new, but specs can use a
Foo.new(output) where output is a StringIO, stub, whatever.

Make sense?