{"id":354,"date":"2014-02-08T10:03:44","date_gmt":"2014-02-08T10:03:44","guid":{"rendered":"http:\/\/www.timwyatt.ca\/test\/?p=354"},"modified":"2014-02-18T20:57:52","modified_gmt":"2014-02-18T20:57:52","slug":"using-test-doubles-in-chefspec","status":"publish","type":"post","link":"https:\/\/www.timwyatt.ca\/test\/?p=354","title":{"rendered":"Using Test Doubles in ChefSpec"},"content":{"rendered":"

One of the improvements to ChefSpec<\/a> in the 3.0 release is the ability to extend test coverage to execute blocks. Doing so requires the infrastructure developer to stub out shell commands run as part of the idempotence check. This is pretty simple as ChefSpec provides a macro to stub shell commands. However doing so where the idempotence check uses a Ruby block is slightly more involved. In this article I explain how to do both.<\/p>\n

Quick overview of ChefSpec<\/h2>\n

ChefSpec is a powerful and flexible unit testing utility for Chef recipes. Extending the popular Ruby testing tool, Rspec<\/a>, it allows the developer to make assertions about the Chef resources declared and used in recipe code. The key concept here is that of Chef resources. When we write Chef code to build infrastructure, we’re using Chef’s domain-specific language to declare resources – abstractions representing the components we need to build and configure. I’m not going to provide a from-the-basics tutorial here, but dive in with a simple example. Here’s a test that asserts that our default recipe will use the package<\/code> resource to install OpenJDK<\/a>.<\/p>\n

require 'chefspec'

RSpec.configure do |config|
  config.platform = 'centos'
  config.version = '6.4'
  config.color = true

  describe 'stubs-and-doubles' do

    let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }

    it 'installs OpenJDK' do
      expect(chef_run).to install_package 'java-1.7.0-openjdk'
    end

  end
end
<\/code><\/pre>\n
If we run this first, we’ll see something like this:<\/p>\n
$ rspec -fd spec\/default_spec.rb 

stubs-and-doubles

================================================================================
Recipe Compile Error
================================================================================

Chef::Exceptions::RecipeNotFound
--------------------------------
could not find recipe default for cookbook stubs-and-doubles

  installs OpenJDK (FAILED - 1)

Failures:

  1) stubs-and-doubles installs OpenJDK
     Failure\/Error: let(:chef_run) {  ChefSpec::Runner.new.converge(described_recipe) }
     Chef::Exceptions::RecipeNotFound:
       could not find recipe default for cookbook stubs-and-doubles
     # .\/spec\/default_spec.rb:10:in `block (3 levels) in <top (required)>'
     # .\/spec\/default_spec.rb:13:in `block (3 levels) in <top (required)>'

Finished in 0.01163 seconds
1 example, 1 failure

Failed examples:

rspec .\/spec\/default_spec.rb:12 # stubs-and-doubles installs OpenJDK
<\/code><\/pre>\n
This is reasonable – I’ve not even written the recipe yet.  Once I add the default recipe, such as:<\/p>\n
package 'java-1.7.0-openjdk'
<\/code><\/pre>\n
Now the test passes:<\/p>\n
$ rspec -fd spec\/default_spec.rb 


stubs-and-doubles
  installs OpenJDK

Finished in 0.01215 seconds
1 example, 0 failures
<\/code><\/pre>\n
Test Doubles<\/h2>\n
ChefSpec works by running a fake Chef run, and checking that the resources were called, with the correct parameters.  Behind the scenes, your cookbooks are loaded, but instead of performing real actions on the system, the Chef Resource class is modified such that messages are sent to ChefSpec instead.  One of the key principles of Chef is that resources should be idempotent<\/em> – the action should only be taken if required, and it’s safe to rerun the resource.  In most cases, the Chef provider knows how to guarantee this – it knows how to check that a package was installed, that a directory was created.  However, if we use an execute resource – a resource where we’re calling directly to the underlying operating system – Chef has no way to tell if the command we called did the right thing.  Unless we explicitly tell Chef how to check, it will just run the command again and again.  This causes a headache for ChefSpec, because it doesn’t have a built-in mechanism for faking operating system calls – so when it comes across a guard, it requires us to help it out, by stubbing the command.<\/p>\n
This introduces some testing vocabulary – vocabulary that is worth stating explicitly, for the avoidance of confusion.  I’m a fan of the approach described in Gerard Meszaros’<\/a> 2007 book xUnit Test Patterns: Refactoring Test Code<\/em><\/a>, and this is the terminology used by Rspec.  Let’s itemise a quick glossary:<\/p>\n