- Updating spec_helper to report coverage

- Updating Gemfile
- Shipping Guardfile
- Adding TESTING.md
- Adding Rakefile
- Updating Test Kitchen config
- Updating Travis config

.gitignore

@@ -12,3 +12,4 @@ Gemfile.lock
 .kitchen
 bin
 .kitchen.local.yml
+.coverage

.kitchen.cloud.yml

@@ -36,13 +36,6 @@ platforms:
     username: ec2-user
     ssh_key: <%= ENV['EC2_SSH_KEY_PATH'] %>
 
-- name: rhel-6.4
-  driver_plugin: ec2
-  driver_config:
-    image_id: ami-7d0c6314
-    username: ec2-user
-    ssh_key: <%= ENV['EC2_SSH_KEY_PATH'] %>
-
 - name: fedora-19
   driver_plugin: digitalocean
   driver_config:

Gemfile

@@ -2,13 +2,13 @@ source 'https://rubygems.org'
 
 group :lint do
   gem 'foodcritic', '~> 3.0'
-  gem 'rubocop', '~> 0.15'
+  gem 'rubocop', '~> 0.18'
   gem 'rainbow', '< 2.0'
 end
 
 group :unit do
-  gem 'berkshelf',  '~> 2.0'
-  gem 'chefspec',   '~> 3.0'
+  gem 'berkshelf',  '~> 3.0.0.beta6'
+  gem 'chefspec',   '~> 3.1'
 end
 
 group :kitchen_common do
@@ -23,3 +23,14 @@ group :kitchen_cloud do
   gem 'kitchen-digitalocean'
   gem 'kitchen-ec2'
 end
+
+group :development do
+  gem 'ruby_gntp'
+  gem 'growl'
+  gem 'rb-fsevent'
+  gem 'guard', '~> 2.4'
+  gem 'guard-kitchen'
+  gem 'guard-foodcritic'
+  gem 'guard-rspec'
+  gem 'guard-rubocop'
+end

Guardfile

@@ -0,0 +1,35 @@
+# A sample Guardfile
+# More info at https://github.com/guard/guard#readme
+
+# guard 'kitchen' do
+#   watch(%r{test/.+})
+#   watch(%r{^recipes/(.+)\.rb$})
+#   watch(%r{^attributes/(.+)\.rb$})
+#   watch(%r{^files/(.+)})
+#   watch(%r{^templates/(.+)})
+#   watch(%r{^providers/(.+)\.rb})
+#   watch(%r{^resources/(.+)\.rb})
+# end
+
+guard 'foodcritic', cookbook_paths: '.', all_on_start: false do
+  watch(%r{attributes/.+\.rb$})
+  watch(%r{providers/.+\.rb$})
+  watch(%r{recipes/.+\.rb$})
+  watch(%r{resources/.+\.rb$})
+  watch('metadata.rb')
+end
+
+guard 'rubocop', all_on_start: false do
+  watch(%r{attributes/.+\.rb$})
+  watch(%r{providers/.+\.rb$})
+  watch(%r{recipes/.+\.rb$})
+  watch(%r{resources/.+\.rb$})
+  watch('metadata.rb')
+end
+
+guard :rspec, cmd: 'bundle exec rspec', all_on_start: false, notification: false do
+  watch(%r{^libraries/(.+)\.rb$})
+  watch(%r{^spec/(.+)_spec\.rb$})
+  watch(%r{^(recipes)/(.+)\.rb$})   { |m| "spec/#{m[1]}_spec.rb" }
+  watch('spec/spec_helper.rb')      { 'spec' }
+end

Rakefile

@@ -36,11 +36,13 @@ namespace :integration do
 
   desc 'Run Test Kitchen with cloud plugins'
   task :cloud do
-    Kitchen.logger = Kitchen.default_file_logger
-    @loader = Kitchen::Loader::YAML.new('./.kitchen.cloud.yml')
-    config = Kitchen::Config.new( :loader => @loader)
-    config.instances.each do |instance|
-      instance.test(:always)      
+    unless ENV['TRAVIS_PULL_REQUEST']
+      Kitchen.logger = Kitchen.default_file_logger
+      @loader = Kitchen::Loader::YAML.new('./.kitchen.cloud.yml')
+      config = Kitchen::Config.new( :loader => @loader)
+      config.instances.each do |instance|
+        instance.test(:always)      
+      end
     end
   end
 end

TESTING.md

@@ -0,0 +1,187 @@
+yum Cookbook TESTING doc
+========================
+
+Bundler
+-------
+A ruby environment with Bundler installed is a prerequisite for using
+the testing harness shipped with this cookbook. At the time of this
+writing, it works with Ruby 2.0 and Bundler 1.5.3. All programs
+involved, with the exception of Vagrant, can be installed by cd'ing
+into the parent directory of this cookbook and running "bundle install"
+
+Rakefile
+--------
+The Rakefile ships with a number of tasks, each of which can be ran
+individually, or in groups. Typing "rake" by itself will perform style
+checks with Rubocop and Foodcritic, ChefSpec with rspec, and
+integration with Test Kitchen using the Vagrant driver by
+default.Alternatively, integration tests can be ran with Test Kitchen
+cloud drivers.
+
+```
+$ rake -T
+rake integration:cloud    # Run Test Kitchen with cloud plugins
+rake integration:vagrant  # Run Test Kitchen with Vagrant
+rake spec                 # Run ChefSpec examples
+rake style                # Run all style checks
+rake style:chef           # Lint Chef cookbooks
+rake style:ruby           # Run Ruby style checks
+rake travis               # Run all tests on Travis
+```
+
+Style Testing
+-------------
+Ruby style tests can be performed by Rubocop by issuing either
+```
+bundle exec rubocop
+```
+or
+```
+rake style:ruby
+```
+
+Chef style tests can be performed with Foodcritic by issuing either
+```
+bundle exec foodcritic
+```
+or
+```
+rake style:chef
+```
+
+Spec Testing
+-------------
+Unit testing is done by running Rspec examples. Rspec will test any
+libraries, then test recipes using ChefSpec. This works by compiling a
+recipe (but not converging it), and allowing the user to make
+assertions about the resource_collection.
+
+Integration Testing
+-------------------
+Integration testing is performed by Test Kitchen. Test Kitchen will
+use either the Vagrant driver or various cloud drivers to instantiate
+machines and apply cookbooks. After a successful converge, tests are
+uploaded and ran out of band of Chef. Tests should be designed to
+ensure that a recipe has accomplished its goal.
+
+Integration Testing using Vagrant
+---------------------------------
+Integration tests can be performed on a local workstation using
+Virtualbox or VMWare. Detailed instructions for setting this up can be
+found at the [Bento](https://github.com/opscode/bento) project web site.
+
+Integration tests using Vagrant can be performed with either
+```
+bundle exec kitchen test
+```
+or
+```
+rake integration:vagrant
+```
+
+Integration Testing using Cloud providers
+-----------------------------------------
+Integration tests can be performed on cloud providers using
+Test Kitchen plugins. This cookbook ships a ```.kitchen.cloud.yml```
+that references environmental variables present in the shell that
+```kitchen test``` is ran from. These usually contain authentication
+tokens for driving IaaS APIs, as well as the paths to ssh private keys
+needed for Test Kitchen log into them after they've been created.
+
+Examples of environment variables being set in ```~/.bash_profile```:
+```
+# digital_ocean
+export DIGITAL_OCEAN_CLIENT_ID='your_bits_here'
+export DIGITAL_OCEAN_API_KEY='your_bits_here'
+export DIGITAL_OCEAN_SSH_KEY_IDS='your_bits_here'
+
+# aws
+export AWS_ACCESS_KEY_ID='your_bits_here'
+export AWS_SECRET_ACCESS_KEY='your_bits_here'
+export AWS_KEYPAIR_NAME='your_bits_here'
+
+# joyent
+export SDC_CLI_ACCOUNT='your_bits_here'
+export SDC_CLI_IDENTITY='your_bits_here'
+export SDC_CLI_KEY_ID='your_bits_here'
+```
+
+Integration tests using cloud drivers can be performed with either
+```
+export KITCHEN_YAML=.kitchen.cloud.yml
+bundle exec kitchen test
+```
+or
+```
+rake integration:cloud
+```
+
+Digital Ocean Hint
+------------------
+At the time of this writing, you cannot find the numerical values
+needed for your SSH_KEY_IDS from the GUI. Instead, you will need to
+access the API from the command line.
+
+    curl -L 'https://api.digitalocean.com/ssh_keys/?client_id=your_bits_here&api_key=your_bits_here'
+
+Words about .travis.yml
+-----------------------
+In order for Travis to perform integration tests on public cloud
+providers, two major things need to happen. First, the environment
+variables referenced by ```.kitchen.cloud.yml``` need to be made
+available. Second, the private half of the ssh keys needed to log into
+machines need to be dropped off on the machine.
+
+The first part is straight forward. The travis gem can encrypt
+environment variables against the public key on the Travis repository
+and add them to the .travis.yml.
+
+```
+gem install travis
+travis encrypt AWS_ACCESS_KEY_ID='your_bits_here' --add
+travis encrypt AWS_SECRET_ACCESS_'your_bits_here' --add
+travis encrypt AWS_KEYPAIR_NAME='your_bits_here' --add
+travis encrypt EC2_SSH_KEY_PATH='~/.ssh/id_ec2.pem' --add
+
+travis encrypt DIGITAL_OCEAN_CLIENT_ID='your_bits_here' --add
+travis encrypt DIGITAL_OCEAN_API_KEY='your_bits_here' --add
+travis encrypt DIGITAL_OCEAN_SSH_KEY_IDS='your_bits_here' --add
+travis encrypt DIGITAL_OCEAN_SSH_KEY_PATH='~/.ssh/id_do.pem' --add
+```
+
+The second part is a little more complicated. Travis ENV variables are
+restricted to 90 bytes, and will not fit an entire SSH key. This can
+be worked around by breaking them up into 90 byte chunks, stashing
+them into ENV variables, then digging them out in the
+```before_install``` section of .travis.yml
+
+Here is an AWK script to do the encoding.
+```
+base64 ~/.ssh/travisci_cook_digitalocean.pem | \
+awk '{
+  j=0;
+  for( i=1; i<length; i=i+90 ) {
+    system("travis encrypt DO_KEY_CHUNK_" j "=" substr($0, i, 90) " --add");
+    j++;
+  }
+}'
+
+base64 ~/.ssh/travisci_cook_ec2.pem | \
+awk '{
+  j=0;
+  for( i=1; i<length; i=i+90 ) {
+    system("travis encrypt EC2_KEY_CHUNK_" j "=" substr($0, i, 90)" --add");
+    j++;
+  }
+}'
+```
+
+Then in .travis.yml:
+```
+before_install:
+- echo -n $DO_KEY_CHUNK_{0..30} >> ~/.ssh/id_do.base64
+- cat ~/.ssh/id_do.base64 | tr -d ' ' | base64 --decode >  ~/.ssh/id_do.pem
+  - echo -n $EC2_KEY_CHUNK_{0..30} >> ~/.ssh/id_ec2.base64
+  - cat ~/.ssh/id_ec2.base64 | tr -d ' ' | base64 --decode > ~/.ssh/id_ec2.pem
+```
+

spec/spec_helper.rb

@@ -1,2 +1,5 @@
 require 'chefspec'
 require 'chefspec/berkshelf'
+
+at_exit { ChefSpec::Coverage.report! }
+