Our First Aruba Feature
Aruba is a Ruby gem that bundles several useful Cucumber step definitions that you can use in your own scenarios. To stay focused on what Aruba has to offer, we’re not going to build our own command-line application right now. Instead, we’ll just use Aruba to test the ruby command-line application. We’re going to start off by writing our feature without installing the aruba gem. Just bear with us; you will soon see it in action. Let’s start with something basic.
Streams and Exit Status
The ruby command has a number of handy command-line options. One of them is the -e option, which lets us execute a one-liner of Ruby code.
Let’s implement a scenario that verifies that the following command works as expected:
| | $ ruby -e 'puts "hello"' |
We’ll start by creating a simple project structure. Create an empty folder with a features directory and a single ruby.feature file:
| | features/ |
| | +-- ruby.feature |
Add the following code to features/ruby.feature:
| | Feature: ruby -e |
| | Scenario: print something |
| | When I run `ruby -e "puts 'hello'"` |
| | Then it should pass with: |
| | """ |
| | hello |
| | """ |
That’s all we need. Now let’s run the feature and let Cucumber lead us to the next step:
| | Feature: ruby -e |
| | |
| | Scenario: print something |
| | When I run ‘ruby -e "puts ’hello’"‘ |
| | Then it should pass with: |
| | """ |
| | hello |
| | """ |
| | |
| | 1 scenario (1 undefined) |
| | 2 steps (2 undefined) |
| | 0m0.019s |
| | |
| | You can implement step definitions for undefined steps with these snippets: |
| | |
| | When(/^I run ‘ruby -e "([^"]*)"‘$/) do |arg1| |
| | pending # Write code here that turns the phrase above into concrete actions |
| | end |
| | |
| | Then(/^it should pass with:$/) do |string| |
| | pending # Write code here that turns the phrase above into concrete actions |
| | end |
As usual, Cucumber is trying to be helpful by suggesting step definition snippets for us. This time, however, we’ll do things a little differently than usual. Instead of copying those step definition snippets to our own files, we’re going to install the aruba gem.
Installing Aruba
There is nothing fancy about installing Aruba. First, we will install the gem. Create a Gemfile like this and then run bundle to install the gems:
| | source :rubygems |
| | group :test do |
| | gem 'cucumber', '3.0.0.pre.1' |
| | gem 'aruba', '0.14.2' |
| | end |
Now that we have Aruba installed, we can tell Cucumber to use it simply by adding a features/support/aruba.rb file with a single line:
| | require 'aruba/cucumber' |
This will load and register several step definitions that are packaged inside the Aruba gem. When we run the feature again, we get a different result:
| | Feature: ruby -e |
| | |
| | Scenario: print something |
| | When I run ‘ruby -e "puts ’hello’"‘ |
| | Then it should pass with: |
| | """ |
| | hello |
| | """ |
| | |
| | 1 scenario (1 passed) |
| | 2 steps (2 passed) |
| | 0m0.328s |
Wow! The steps no longer show up as undefined; in fact, they’re passing. This is because Aruba comes bundled with some generic step definitions for testing command-line applications. It just so happens that the steps we wrote in our scenario have matched perfectly with a few of those generic step definitions. Aruba has helped get our scenario up and running in next to no time, without having to write a single line of Ruby code. Let’s dig a little deeper to find out how that works.
Examining Aruba’s Step Definitions
When you have a large library of step definitions, especially one provided by a third-party like Aruba, it can be useful to ask Cucumber for a complete list of all the step definitions. You can do that using the stepdefs formatter, like so:
| | $ cucumber --format stepdefs |
What you should see is a long list of step definitions. If you have colors enabled in your terminal, you’ll see that two of the step definitions are highlighted in green, indicating that they’ve been used and have passed. Those step definitions are as follows:
|
Executes the command between the backticks in a child process, waits for it to finish, and remembers the STDOUT, STDERR, and exit status. | ||
|
Checks that the exit status indicated pass or fail as expected. Verifies that the string you passed in between triple quotes appears in either STDOUT or STDERR. If either of these checks fail, Aruba raises an exception, and the step fails. |
Let’s try to provoke a failure. Change the feature to say Then it should fail with: instead of Then it should pass with:. That should give you the following output:
| | Feature: ruby -e |
| | |
| | Scenario: print something |
| | When I run ‘ruby -e "puts ’hello’"‘ |
| | Then it should fail with: |
| | """ |
| | hello |
| | """ |
| | expected "/usr/bin/ruby -e "puts ’hello’"" not to be |
| | successfully executed (RSpec::Expectations::ExpectationNotMetError) |
| | features/ruby.feature:4 |
| | |
| | Failing Scenarios: |
| | cucumber features/ruby.feature:2 |
| | |
| | 1 scenario (1 failed) |
| | 2 steps (1 failed, 1 passed) |
| | 0m0.339s |
We expected the Ruby process to fail, which technically speaking means exiting with a nonzero exit status. However, ruby executed our simple program quite perfectly, so Aruba correctly failed our step.
Now that you understand the fundamentals of how Aruba and Cucumber work together to test command-line tools, we’ll look at how to work with files.
Try This
Change the feature back to the original Then it should pass with: step.
-
Can you make the test fail by changing the Ruby command to produce a nonzero exit status?
-
What happens if you change the expected output to something different from hello, for example bonjour?