I have a command line (NON-RAILS) application written in pure Ruby that I'm driving out through Cucumber and RSpec. It follows the typical application hierarchy of lib, bin, spec, and feature directories.
Up until now, I've followed the traditional process of writing a failing Cucumber feature/scenario, dropping down to RSpec to drive out the supporting lib files, then getting the scenario to pass.
Unfortunately, this doesn't seem to be as straight forward when driving out the main application entry point in "bin/my_application.rb". The main issue for me is that I'm not describing a class in RSpec, it's a sequential Ruby script for managing the application's classes and initialization via command line parameters and options.
"bin/my_application.rb" is just a smal开发者_如何转开发l shell-executed wrapper for parsing command line options and passing them onto my main application class as initializer options. I'd still like to test the behavior of the bin script (e.g. MyApp.should_receive(option_a).with(parameter)).
Any suggestions/thoughts/advice? Is this a normal test strategy for driving out command line Ruby script behavior?
Thanks in advance.
Not sure I fully comprehend what you're asking, but I'd say that if you want to use RSpec to test your parameter passing it should be easy enough to do. Say you have your wrapper script:
# my_application.rb
command = Command.new
command.foo = true if ARGV[0]
command.bar = true if ARGV[1]
command.baz = false if ARGV[2]
command.make_dollars(1000000)
Just mix it up and make it a class suitable for testing.
# command_runner.rb
class CommandRunner
def run(args, command = Command.new)
command.foo = true if args[0]
command.bar = true if args[1]
command.baz = false if args[2]
command.make_dollars(1000000)
end
end
# my_application.rb
CommandRunner.new.run(ARGV)
Now the only thing you don't have tested is your default parameter on the run
command and the one line in the file my_application.rb
Hope that helps. Brandon
精彩评论