Here at Solano Labs we package much of the code we deploy as gems. This includes the tddium command line interface as well as internal tools. As you would expect, we use a combination of RSpec and Cucumber to test these tools. We’ve found Cucumber and Aruba to be particularly useful tools for testing the CLI component of Tddium. Some of our other internal gems are deployed as gem files rather than distributed via RubyGems. Testing these gems using Cucumber is a little trickier as we want to test them in a pristine environment but we can’t just force the installation of the gem via the Gemfile, at least not without doing something gross like forcing a second checkout with a Gemfile git URL. Instead, we’ve written a simple helper that builds the gem from its gemspec and installs it into an alternate gem directory. We then point the appropriate Cucumber scenarios at the alternate gem directory in the test environment.

The basic idea is to build the gem once, install it into an alternate gem directory, and let each scenario in a feature use the one copy of the gem. Each scenario is configured to use the alternate gem directory independently using an appropriate Before block; the environment is restored in an After block. The CukeGem class takes care of the dirty work of altering the environment so that the gem under test gets built and run properly. The implementation goes in features/support/gem.rb. You can then add the following snippet to your features/support/env.rb:

1

2

3

4

5

6

7

Before('@gem')do

CukeGem.setup('path/to/gem.gemspec')

end

After('@gem')do

CukeGem.teardown

end

And tag each scenario that requires the gem with @gem (or another tag of your choosing). The first time the Before block runs, it will build and install the gem; subsequent calls will only update the environment.

The approach you’re talking about could work, but I’d suggest not using Aruba’s process management to start the server unless you need to test the servers output as well. I’m assuming you start the server app before all of the scenarios tagged @server. Then you could have a Before(“@server”) block that did the server start for you, and wrote the servers output to stdout or to a log file.