I have been using Pry (an alternative to irb) to debug and develop my tests. When I integrated ci_reporter into my TestUnit output, anytime that the Pry binding.pry is referenced in my code to bring up pry inside the program, I get an infinite loop:
TypeError: wrong argument type CI::Reporter::OutputCapture (expected File)
from /home/brian/.rvm/gems/ree-1.8.7-2012.02@reverbnation/gems/pry-0.9.8.2/lib/pry/pry_instance.rb:525:in `readline'
Wow, that's a good one! ci_reporter overrides and wraps $stdout and $stderr with OutputCapture, which is a DelegateClass(IO). I guess Pry is expecting a concrete instance of File somewhere in its code. Maybe this is a bug in pry, that's being too strict in what it expects?
You should be able to work around this by setting ENV['CI_CAPTURE'] = 'off' before running the test case, or alternatively you might be able to avoid the situation by setting $stdout, $stderr = STDOUT, STDERR right before invoking pry.
ENV['CI_CAPTURE'] = 'off'
$stdout, $stderr = STDOUT, STDERR
Thanks for the quick response!
Your suggestion to set $stdout, $stderr = STDOUT, STDERR before calling binding.pry seems to work well! The only downside is that the reporter stops recording output, and there doesn't seem to be a way to give it back. Oh well, that is ok, as I just need the ability to toggle pry on and off temporarily without modifying the actual test suites and ci_reporter requirements themselves.
You might want to add this fix to your readme page for future use!
Would you mind filing an issue on pry's tracker (referencing this one) to see if there's anything they can do on their end?
The only other fix I can see would be to make OutputCapture a subclass of File and add delegate logic there.
Just FYI, I did file an issue on Pry's tracker here: pry/pry#490
Just a quick note about my findings so far:
The problem is caused by the builtin readline library on ruby 1.8.7 (it seems to have been fixed by 1.9.2) that requires $stdout (and $stdin) to be a subclass of File.
It's probably hard to fix this at the Pry level (as it's unlikely we always want to clobber a user's custom $stdout/$stdin) but we may be able to come up with a heuristic function for when it's safe to do so.
Thanks for the investigation. If 1.8.7 requies them to be subclasses of File then I should probably address it here.
Accommodate 1.8.7 which requires std streams to be subclasses of IO