rspec users - Sep 2010 - 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?  ;-)   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:
> 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?  ;-)   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 Remes''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


-- 
med v?nlig h?lsning
David J. Hamilton

Why not stub System.out.println, possibly with message expectations if
necessary?
>
> On Sep 30, 2010, at 10:06 AM, GregD wrote:
>
>> 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?  ;-)   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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Jan 12, 2011, at 9:52 AM, Chuck Remes wrote:
> 
> On Sep 30, 2010, at 10:06 AM, GregD wrote:
> 
>> 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?  ;-)   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?
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?