Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Chef cookbook that provides dead simple ability to verify node setup after chef run using cucumber & aruba

branch: master

This branch is 0 commits ahead and 0 commits behind master

Fetching latest commit…

Cannot retrieve the latest commit at this time

README.md

simple_cuke

Description

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.

Requirements

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).

Attributes

  • node["simple_cuke"]["suite_path"] - Location for the test suite on the target node (/var/chef/handlers/suite by default)
  • node["simple_cuke"]["reporter"] - Reporter which would be used to notify you results of tests.

Usage

  1. Install this cookbook to your chef repo. (git clone git://github.com/iafonov/simple_cuke.git cookbooks/simple_cuke)
  2. Add recipe[simple_cuke] to run_list
  3. Start writing cucumber features and place them in files/default/suite/features folder
  4. Run chef-client and enjoy

How it works

After each 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.

Aruba

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.

Custom steps

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.

Examples

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 |

Reporters

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 custom)

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:

  1. Default recipe synchronizes the files/default/suite cookbook's folder with remote node via calling remote_directory LWRP.
  2. Chef handler is registered.
  3. When handler is executed it installs the bundle (it consists of cucumber & aruba) and runs cucumber features.

© 2012 Igor Afonov

Something went wrong with that request. Please try again.