This chef cookbook provides dead simple way to test and verify node's setup after chef run using cucumber and aruba. Unlike similar tools it's designed to be fully understood and ready to use in less then 5 minutes by the average developer.
It could be used as a tool to support BDD style in development of your infrastructure and as a regression testing tool.
Cookbook depends on Opscode's chef_handler cookbook. (Run
knife cookbook site install chef_handler to install it)
There are no additional limitations on environment. You can use it with any kind of chef (hosted/private/solo).
node["simple_cuke"]["suite_path"]- Location for the test suite on the target node (
node["simple_cuke"]["reporter"]- Reporter which would be used to notify you results of tests.
node["simple_cuke"]["suite_cookbook"]- Cookbook for the test suite diectory structure (uses
- Install this cookbook to your chef repo. (
git clone git://github.com/iafonov/simple_cuke.git cookbooks/simple_cuke)
- Start writing cucumber features and place them in
files/default/featuresfolders of cookbooks
How it works
chef-client run a set of cucumber features is executed on a target node. As simple as it is. No black magic involved*.
Running role specific features
Add role name as tag to the scenario or feature and it would be run only on nodes that have this role. Features/scenarios without tags would be run always.
The cookbook will automatically install and link aruba gem for you. Aruba is a set of handy cucumber steps that are intended to test command line applications and test manipulation with file system - this is exactly what is needed during verification of infrastructure setup. I recommend you to quickly go through provided steps definitions to prevent reintroducing already available steps. You can see the complete definitions list here.
There are no restrictions - you can use your own defined steps. Put the step definitions into
features/step_definitions/[younameit]_steps.rb file and they would be loaded automatically.
Simple example - check that Apache is running:
@appserver Feature: Application server Scenario: Apache configuration check When I successfully run `ps aux` Then the output should contain "apache"
Slightly more advanced example: check services are running, bind to their ports and aren't blocked by firewall:
@base Feature: Services Scenario Outline: Service should be running and bind to port When I run `lsof -i :<port>` Then the output should match /<service>.*<user>/ Examples: | service | user | port | | master | root | 25 | | apache2 | www-data | 80 | | dovecot | root | 110 | | mysqld | mysql | 3306 | Scenario Outline: Service should not be blocked by firewall When I run `ufw status` Then the output should match /<service>.*<action>/ Examples: | service | action | | OpenSSH | ALLOW | | Apache | ALLOW | | Postfix | ALLOW |
By default reporting is done to console but you can override this behavior and add custom reporter to
files/default/reporters folder. Reporter is a plain ruby class with the following skeleton:
class CustomReporter def success(report) end def fail(report) end end
You can set reporter via
node["simple_cuke"]["reporter"] attribute. (If your class has name
CustomReporter you should set this attribute value to
For example you can send an email if test suite failed, write it to file or notify monitoring service.
How it works (in details)
The idea behind implementation is to be as simple and straightforward as possible. The workflow consists of the following three steps:
- Default recipe synchronizes the
files/default/suitefolders of cookbooks with remote node via calling
- Chef handler is registered.
- When handler is executed it installs the bundle (it consists of cucumber & aruba) and runs cucumber features.
© 2012 Igor Afonov