Make cucumber-nagios features parameterised

[auxesis]

If you want to run the same scenario across multiple hosts, you can write a scenario outline. But what if you don't know the host you want to run it against? What if you want to specify the host on the command line like this:

cucumber-nagios features/backups.feature backup1.example.org
cucumber-nagios features/backups.feature backup33.example.org

This would be awesome.

[dillytaint]

Yes please!

[bjoernalbers]

This would be awesome.

Yes, and it would also align the usage with nagios plugin guidelines, which define the reserved "-H" option, i.e.:

$USER7$/bin/cucumber-nagios -H $HOSTADDRESS$ $USER7$/features/dns.feature

However, most macros are also provided as environment variables by nagios with a "NAGIOS_"-prefix (http://nagios.sourceforge.net/docs/3_0/macros.html). I've used this feature where I wanted to check my dns-feature for each nameserver (primary and secondary):

Given /^a valid nameserver by nagios$/ do
  var = 'NAGIOS_HOSTADDRESS'
  nameserver = ENV[var]
  nameserver.should_not be_blank, "ERROR: environment variable #{var} not set"
  @resolver = Resolv.new([Resolv::DNS.new(:nameserver => nameserver)])
end

HTH, Björn

[mkrakowitzer]

this would be a nice feature.

[mjutras]

+1 ...

[josephholsten]

This could be provided exposing the HOSTADDRESS as an environment variable.

We'll need replacements for at least these steps:

Given /I have a AMQP server on (.+)$/
When /I fetch headers from "(.*)"/
When /^I go to "(.*)"$/

How do these steps sound?

Given /^I have a AMQP server on the host$/
When /^I go to the host$/

We might implement it in place with a transform, but those can get magical and not in a good way.

Then there's the deep task of cuken integration.