[rspec-users] How to spec a (Trollop-based) binary’s internal state?
pergesu at gmail.com
Fri Nov 7 10:42:21 EST 2008
"Shot (Piotr Szotkowski)" <shot at hot.pl> writes:
> I’m trying to spec a ‘binary’, and as previously discussed on this list,
> I’m trying to do it ‘from outside’ – i.e., by calling it with Kernel#`
> and observing the (side-)effects.
> Unfortunately, this doesn’t really let me spec expectations about its
> internals. Let’s assume I have a -d flag and I parse it with Trollop to
> set Conf.debug:
> opts = Trollop::options do
> opt :debug, 'Print debug info', :default => false
> Conf.debug = opts[:debug]
> To have a spec that actually expects
> this, I’d write something like this:
> it 'should set the debug option properly' do
> `binary -d`
> Conf.should_receive(:debug=).with true
> This obviously doesn’t work, as the Kernel#` call is executed in
> a context that is not visible from the current Ruby interpreter.
> I assume that eval()-ing the binary (much like Rick Bradley does¹
> for specing flog) would be the way to go, but then I don’t know how
> to pass the -d flag to Trollop.
> ¹ http://rubyhoedown2008.confreaks.com/11-rick-bradley-flog-test-new.html
> What would be the best practice in this case? Prepare ARGV for Trollop
> so that it believes we are calling the binary with the -d flag and then
> eval the binary, or run the binary with Kernel#`, pass it something
> that should generate debug output and then check whether the output
> was generated (rather than check whether the binary set Conf.debug)?
> -- Shot
When you use backticks to execute the binary, it runs in a separate
process, so you can't use mock expectations like that.
I think you're kind of missing the intention though...what I think you
want to do is write features with cucumber that use the built binary
from the outside. But when you write code-level examples, you are not
going to run the binary. You're just writing examples at a lower level,
directly for the objects. Make sense?
More information about the rspec-users