Running Rubocop against an Entire Repository

In this example, we’re going to run Rubocop against a new repository to verify the output is as expected, with no errors.

First of all, let’s create a new repository using chef generate app:

PS C:UsersStuartPreston> chef generate app chefazure-ch06              

This should generate an output similar to the following, and I have shortened the (lengthy) output:

Compiling Cookbooks...
Recipe: code_generator::app
  * directory[C:/Users/StuartPreston/chefazure-ch06] action create
    - create new directory C:/Users/StuartPreston/chefazure-ch06
  * template[C:/Users/StuartPreston/chefazure-ch06/.kitchen.yml] action create
    - create new file C:/Users/StuartPreston/chefazure-ch06/.kitchen.yml

    [... files are created here ...]
  * execute[initialize-git] action run
    - execute git init .
  * cookbook_file[C:/Users/StuartPreston/chefazure-ch06/.gitignore] action create
    - create new file C:/Users/StuartPreston/chefazure-ch06/.gitignore
    - update content in file C:/Users/StuartPreston/chefazure-ch06/.gitignore from none to 33d469
    (diff output suppressed by config)

Now let’s move into our repo directory:

PS C:UsersStuartPreston> cd chefazure-ch06              

and execute Rubocop with no other command-line options:

PS C:UsersStuartPrestonchefazure-ch06> rubocop                
Inspecting 7 files
.......

7 files inspected, no offenses detected

As you can see from the output we have no offenses detected. That’s a good start. Let’s add some code to a recipe and see if Rubocop detects anything wrong.

Detecting and Correcting Rubocop Violations

Let’s open up our code editor (in my case Visual Studio Code):

PS C:UsersStuartPrestonchefazure-ch06> code .              

Now navigate to cookbookschefazure-ch06 ecipes and open up the default.rb file. Let’s add a simple log resource to our recipe as follows:

#
# Cookbook Name:: chefazure-ch06
# Recipe:: default
#
# Copyright (c) 2016 The Authors, All Rights Reserved.

log "Hello, World!"                    

The code should look similar to the code shown in Figure 6-1. Save the file.

Figure 6-1. Adding a log resource to the default recipe in our cookbook

Now we’re going to run Rubocop again and see what results we get:

PS C:UsersStuartPrestonchefazure-ch06> rubocop                
Inspecting 7 files
..C....

Offenses:

cookbooks/chefazure-ch06/recipes/default.rb:7:5: C: Prefer single-quoted strings when you don't need string interpolation or special symbols.
log "Hello, World!"
    ^^^^^^^^^^^^^^^
cookbooks/chefazure-ch06/recipes/default.rb:7:20: C: Final newline missing.
log "Hello, World!"

7 files inspected, 2 offenses detected

As we can see from the output, two style offenses have been detected in the code from adding one seemingly innocuous line of code. Impressive! We can now correct them and try it again. We can make the changes manually ourselves or use the (experimental) autocorrect feature of Rubocop.

Rubocop Autocorrect

While there are some Rubocop violations that have multiple possible fixes, Rubocop does a good job of correcting code automatically by simply typing rubocop -a.

Autocorrect works best when there is only one solution to the problem; otherwise it will leave the offense alone. Let’s run rubocop -a against our code and see what happens:

PS C:UsersStuartPrestonchefazure-ch06> rubocop -a                
Inspecting 7 files
..C....

Offenses:

cookbooks/chefazure-ch06/recipes/default.rb:7:5: C: [Corrected] Prefer single-quoted strings when you don't need string interpolation or special symbols.
log "Hello, World!"
    ^^^^^^^^^^^^^^^
cookbooks/chefazure-ch06/recipes/default.rb:7:20: C: [Corrected] Final newline missing.
log "Hello, World!"

7 files inspected, 2 offenses detected, 2 offenses corrected

We can see in our example we now have corrected two offenses. This can also be seen in Figure 6-2. Our quoted string was changed to single quotes, and a new line was added at the end of the file for consistency.

Figure 6-2. Our corrected recipe after being run through Rubocop in autocorrect mode

Suppressing Rubocop Offenses

While it would be great if we could use and enforce the default Rubocop rules for all our projects without modification, sometimes you will break so many rules that you want to defer fixing them until a later point, or perhaps you have a rule that simply doesn’t make sense for your project.

If you have a legitimate reason to suppress an offense there are a few ways to accomplish this:

1. You may generate a .rubocop_todo.yml file from your failing tests, with the intent of fixing them later.

2. You may add blanket exclusions to your .rubocop.yml file.

3. You may add per-line exclusions as a comment in each file.

4. You may exclude sections of files.

5. You may exclude entire files.

#
# Cookbook Name:: chefazure-ch06
# Recipe:: default
#
# Copyright (c) 2016 The Authors, All Rights Reserved.

log "Hello, World!"                      

PS C:UsersStuartPrestonchefazure-ch06> rubocop --auto-gen-config                  
Inspecting 7 files
..C....

Offenses:

cookbooks/chefazure-ch06/recipes/default.rb:7:5: C: Prefer single-quoted strings when you don't need string interpolation or special symbols.
log "Hello, World!"
    ^^^^^^^^^^^^^^^

7 files inspected, 1 offense detected
Created .rubocop_todo.yml.
Run `rubocop --config .rubocop_todo.yml`, or
add inherit_from: .rubocop_todo.yml in a .rubocop.yml file.

PS C:UsersStuartPrestonchefazure-ch06> cat .rubocop_todo.yml                  
# This configuration was generated by
# `rubocop --auto-gen-config`
# on 2015-11-05 16:18:50 +0000 using RuboCop version 0.34.2.
# The point is for the user to remove these configuration records
# one by one as the offenses are removed from the code base.
# Note that changes in the inspected code, or installation of new
# versions of RuboCop, may require this file to be generated again.

# Offense count: 1
# Cop supports --auto-correct.
# Configuration parameters: EnforcedStyle, SupportedStyles.
Style/StringLiterals:
  Enabled: false

inherit_from: .rubocop_todo.yml

PS C:UsersStuartPrestonchefazure-ch06> rubocop                  
Inspecting 7 files
.......

7 files inspected, no offenses detected

PS C:UsersStuartPrestonchefazure-ch06> cp .rubocop_todo.yml .rubocop.yml                  
PS C:UsersStuartPrestonchefazure-ch06> rubocop                  
Inspecting 7 files
.......

7 files inspected, no offenses detected

Adding Per-line Exclusions

To exclude cops from running on a per-line basis, we need to add a Ruby comment to that line.

First, let’s remove our .rubocop.yml to bring back an error that needs correcting, and run Rubocop again to detect our mistake. We can use the -D parameter to see the full cop name, which we’ll need to use to specify our exclusion.

PS C:UsersStuartPrestonchefazure-ch06> rm .rubocop.yml                  
PS C:UsersStuartPrestonchefazure-ch06> rubocop -D                  
Inspecting 7 files
..C....

Offenses:

cookbooks/chefazure-ch06/recipes/default.rb:7:5: C: Style/StringLiterals: Prefer single-quoted strings when you don't need string interpolation or special symbols.
log "Hello, World!"
    ^^^^^^^^^^^^^^^

7 files inspected, 1 offense detected

We can take the cop name “Style/StringLiterals” and put that in a comment against our code with a rubocop:disable directive, as shown in Figure 6-3. The resulting code should look like this:

Figure 6-3. Suppressing a rubocop rule at line level

#
# Cookbook Name:: chefazure-ch06
# Recipe:: default
#
# Copyright (c) 2016 The Authors, All Rights Reserved.

log "Hello, World!" # rubocop:disable Style/StringLiterals                  

Now when you execute rubocop -D again, there should be no offenses detected:

PS C:UsersStuartPrestonchefazure-ch06> rubocop -D                  
Inspecting 7 files
.......

7 files inspected, no offenses detected

#
# Cookbook Name:: chefazure-ch06
# Recipe:: default
#
# Copyright (c) 2016 The Authors, All Rights Reserved.

# rubocop:disable Style/StringLiterals                      
log "Hello, World!"
# rubocop:enable Style/StringLiterals                      

PS C:UsersStuartPrestonchefazure-ch06> rubocop                  
Inspecting 7 files
.......

7 files inspected, no offenses detected

#
# Cookbook Name:: chefazure-ch06
# Recipe:: default
#
# Copyright (c) 2015 The Authors, All Rights Reserved.

# rubocop:disable all                      
log "Hello, World!"
# rubocop:enable all                      

PS C:UsersStuartPrestonchefazure-ch06> rubocop                  
Inspecting 7 files
.......

7 files inspected, no offenses detected

Rubocop Options

Rubocop can be executed with a range of options; these are all documented in Table 6-1, you can also get the list by running rubocop -h:

PS C:UsersStuartPreston> rubocop -h              

That covers the basics of Rubocop. Where possible try to maintain zero violations in your project or distribute your .rubocop.yml files with your repo so that it is clear what is acceptable to the project to be ignored or suppressed. Let’s move on to some of the other quality tools within the ChefDK.

FoodCritic Rules

There are currently 58 default FoodCritic rules that are executed against the specified cookbooks. A complete list can be generated by using the command foodcritic -l:

PS C:UsersStuartPrestonchefazure-ch06> foodcritic -l              
FC001: Use strings in preference to symbols to access node attributes
FC002: Avoid string interpolation where not required
FC003: Check whether you are running with chef server before using server-specific features
FC004: Use a service resource to start and stop services
FC005: Avoid repetition of resource declarations
FC006: Mode should be quoted or fully specified when setting file permissions
FC007: Ensure recipe dependencies are reflected in cookbook metadata
FC008: Generated cookbook metadata needs updating
FC009: Resource attribute not recognised
FC010: Invalid search syntax
FC011: Missing README in markdown format
FC012: Use Markdown for README rather than RDoc
FC013: Use file_cache_path rather than hard-coding tmp paths
FC014: Consider extracting long ruby_block to library
FC015: Consider converting definition to a LWRP
FC016: LWRP does not declare a default action
FC017: LWRP does not notify when updated
FC018: LWRP uses deprecated notification syntax
FC019: Access node attributes in a consistent manner
FC021: Resource condition in provider may not behave as expected
FC022: Resource condition within loop may not behave as expected
FC023: Prefer conditional attributes
FC024: Consider adding platform equivalents
FC025: Prefer chef_gem to compile-time gem install
FC026: Conditional execution block attribute contains only string
FC027: Resource sets internal attribute
FC028: Incorrect #platform? Usage
FC029: No leading cookbook name in recipe metadata
FC030: Cookbook contains debugger breakpoints
FC031: Cookbook without metadata file
FC032: Invalid notification timing
FC033: Missing template
FC034: Unused template variables
FC037: Invalid notification action
FC038: Invalid resource action
FC039: Node method cannot be accessed with key
FC040: Execute resource used to run git commands
FC041: Execute resource used to run curl or wget commands
FC042: Prefer include_recipe to require_recipe
FC043: Prefer new notification syntax
FC044: Avoid bare attribute keys
FC045: Consider setting cookbook name in metadata
FC046: Attribute assignment uses assign unless nil
FC047: Attribute assignment does not specify precedence
FC048: Prefer Mixlib::ShellOut
FC049: Role name does not match containing file name
FC050: Name includes invalid characters
FC051: Template partials loop indefinitely
FC052: Metadata uses the unimplemented "suggests" keyword
FC053: Metadata uses the unimplemented "recommends" keyword

Each FoodCritic rule is documented at http://foodcritic.io - for example Figure 6-4 shows the first rule that is tested against your cookbook: FC001.

Figure 6-4. FoodCritic rule explanation as seen at http://www.foodcritic.io/#FC001

To see FoodCritic in action, let’s go back to our recipe cookbooks/chefazure-ch06/default.rb in our code editor and modify it as follows so that when executed it would log three messages as part of the Chef Client run:

#
# Cookbook Name:: chefazure-ch06
# Recipe:: default
#
# Copyright (c) 2015 The Authors, All Rights Reserved.

log 'Hello, Adam!' do                    
  level :info                
end                    

log 'Hello, Alan!' do                    
  level :info                
end                    

log 'Hello, Ross!' do                    
  level :info                
end                    

Now let’s see what FoodCritic identifies about our cookbook:

C:UsersStuartPrestonchefazure-ch06> foodcritic cookbooks/chefazure-ch06                
FC005: Avoid repetition of resource declarations: cookbooks/chefazure-ch06/recipes/default.rb:7
FC011: Missing README in markdown format: cookbooks/chefazure-ch06/README.md:1

We can see that we have triggered the rule FC005: Avoid repetition of resource declarations. If we look up this rule (as seen in Figure 6-5), we can see the problem and a possible solution is presented to us.

Figure 6-5. FoodCritic rule explanation as seen at http://foodcritic.io/#FC005

We can now go back to our recipe and change it to match the desired style:

#
# Cookbook Name:: chefazure-ch06
# Recipe:: default
#
# Copyright (c) 2015 The Authors, All Rights Reserved.

%w(Adam Alan Ross).each do |friend|                    
  log "Hello, #{friend}!" do                
    level :info                
  end                
end                    

We can now retest and ensure we do not get any FC005 matches returned:

PS C:UsersStuartPrestonchefazure-ch06> foodcritic cookbooks/chefazure-ch06                

We are left with one further warning that we will suppress in the next section:

FC011: Missing README in markdown format: cookbooks/chefazure-ch06/README.md:1

Suppressing FoodCritic Messages

Rules in FoodCritic are identified by a tag, which takes the format FC + number: for example, FC001. To exclude rules with specific tags, the -t option is used with a ∼ in front of the tag name. For example, if we wished to exclude the tag FC011: Missing README in markdown format we would specify the following command at the command line:

PS C:UsersStuartPrestonchefazure-ch06> foodcritic cookbooks/chefazure-ch06 -t ∼FC011                

The results list should now be an empty line, indicating that no issues were found with the cookbook:

PS C:UsersStuartPrestonchefazure-ch06> echo "∼FC011" > cookbooks/chefazure-ch06/.foodcritic                  
PS C:UsersStuartPrestonchefazure-ch06> foodcritic cookbooks/chefazure-ch06                  

Further FoodCritic Options

FoodCritic has a number of additional options that can be seen by typing foodcritic -h as shown in Table 6-2.

Now that we’ve covered the basic of code linting and static analysis, we’ll move on to explain how to test your recipes.

Generating ChefSpec tests for Cookbooks

Luckily for us, cookbooks by default have a default set of ChefSpec tests created. They can be found under <cookbook>/spec/unit/recipes. Test ‘specifications’ by convention are named _spec.rb so that tools can find them by this pattern.

Figure 6-8 shows us the structure that is generated and a default test that has been generated.

Figure 6-8. Directory structure showing the default test specification file created by chef generate app

Executing ChefSpec Tests

ChefSpec tests are executed from the cookbook directory and not the root of the repo. So let’s execute the default tests by changing directory into the cookbook directory and running rspec.

PS C:UsersStuartPrestonchefazure-ch06> cd cookbooks/chefazure-06                
PS C:UsersStuartPrestonchefazure-ch06cookbookschefazure-ch06> rspec -f documentation                

chefazure-ch06::default
  When all attributes are default, on an unspecified platform
    converges successfully

Finished in 0.71881 seconds (files took 15.13 seconds to load)
1 example, 0 failures

We can see from the output that we have one example, zero failures. This is the expected behavior. Let’s break down the default tests to understand what it is doing a bit more.

#
# Cookbook Name:: chefazure-ch06
# Spec:: default
#
# Copyright (c) 2016 The Authors, All Rights Reserved.

require 'spec_helper'

The statement require 'spec_helper' means that this file is including some statements from the common file spec/spec_helper.rb. All of the spec files will require this statement at the top of the file otherwise ChefSpec will not get loaded correctly. Let’s have a look at the default test:

describe 'chefazure-ch06::default' do
  context 'When all attributes are default, on an unspecified platform' do
    let(:chef_run) do
      runner = ChefSpec::ServerRunner.new
      runner.converge(described_recipe)
    end

    it 'converges successfully' do                
      expect { chef_run }.to_not raise_error                
    end                
  end
end

Working outwards from the test:

• The test itself (it 'converges successfully') is testing that the chef_run does not raise an error when it converges.

• The let statement assigns variables that can be used elsewhere in the context block (in our case, chef_run).

• The context block (context 'When all attributes are default, on an unspecified platform') provides a grouping for the test, and can be used to run different tests according to the platform being tested (not used here).

• The describe statement (describe 'chefazure-ch06::default') is the scenario that is being tested. In this case a recipe: chefazure-ch06::default.

What we are trying to do with ChefSpec test is provide tests that cover each scenario you are writing recipes for, so that we can write the minimum recipe code that satisfies the test and eventually allows safe refactoring of the recipe code.

Imagine you have a scenario that means you want to write a recipe to ensure a specific file is deleted. Most of the tests follow the pattern of the following:

expect(chef_run).to <action>_<resource>('<name>')

We know in Chef to write this recipe we need to use the file resource and the :delete action, so our resulting test would look something like this:

expect(chef_run).to delete_file('c:/test.txt')

The resource in our recipe would look something like this:

file 'c:/test.txt' do
  action :delete
end

We can see the resource name, the name of the file and the action match those we specified in the test.

Let’s try it. First of all, open up the cookbooks/chefazure-ch06/spec/unit/recipes/default_spec.rb in your text editor and add the following text within the context block:

it 'deletes the test.txt file' do
  expect(chef_run).to delete_file('c:/test.txt')
end

The resulting file should look as shown in Figure 6-9:

Figure 6-9. Adding a test to our default_spec.rb file

Now we can execute our test by running rspec with the -f documentation and --color options:

PS C:UsersStuartPrestonchefazure-ch06cookbookschefazure-ch06> rspec -f documentation --color              

After a few seconds you should see a similar test failure to below.

chefazure-ch06::default
  When all attributes are default, on an unspecified platform
    converges successfully
    deletes the test.txt file (FAILED - 1)

Failures:

  1) chefazure-ch06::default When all attributes are default, on an unspecified platform
deletes the test.txt file
     Failure/Error: expect(chef_run).to delete_file('c:/test.txt')
       expected "file[c:/test.txt]" with action :delete to be in Chef run. Other file
resources:

     # ./spec/unit/recipes/default_spec.rb:21:in `block (3 levels) in <top (required)>'

Finished in 1.06 seconds (files took 15.93 seconds to load)
2 examples, 1 failure

Failed examples:

rspec ./spec/unit/recipes/default_spec.rb:20 # chefazure-ch06::default When all attributes
are default, on an unspecified platform deletes the test.txt file

The output shows you exactly which test has failed so you can go back to it and resolve it. It is, of course, correct that this test fails - we haven’t written the recipe yet! This style of test-first development is a commonly accepted practice in the development world. We first of all write our test, see it fail, write the minimum amount of code to satisfy the test, and then refactor our solution, maintaining test success all the while. Figure 6-10 shows the workflow behind this practice.

Figure 6-10. Test-first development process (image credit: Xavier Pigeon)

We can now add to our default.rb recipe to satisfy the test:

file 'c:/test.txt' do
  action :delete
end

Having done that, let’s retry our test using rspec:

PS C:UsersStuartPrestonchefazure-ch06cookbookschefazure-ch06> rspec -f documentation --color                

chefazure-ch06::default
  When all attributes are default, on an unspecified platform
    converges successfully
    deletes the test.txt file

Finished in 1.05 seconds (files took 14.8 seconds to load)
2 examples, 0 failures

We have satisfied our tests and everything is ‘green’.

Adding Code Coverage to Cookbook Tests

ChefSpec offers a crude code coverage mechanism to let you know which resources have been touched by your tests as a percentage.

To enable it, simply add the following line to your spec_helper.rb file (found in your cookbook within the spec folder):

at_exit { ChefSpec::Coverage.report! }

Now when you run the RSpec tests you should get a coverage report at the end:

PS C:UsersStuartPrestonchefazure-ch06cookbookschefazure-ch06> rspec -f documentation --color                
chefazure-ch06::default
  When all attributes are default, on an unspecified platform
    converges successfully
    deletes the test.txt file

Finished in 9.38 seconds (files took 5.04 seconds to load)
2 examples, 0 failures

ChefSpec Coverage report generated...
  Total Resources:   1
  Touched Resources: 1
  Touch Coverage:    100.0%

You are awesome and so is your test coverage! Have a fantastic day!

Now we have seen how to add unit tests to your cookbooks to simulate behavior, we can now take a look at the other side of testing, using Test Kitchen and InSpec to perform acceptance tests on your recipes against real servers.

Creating an Instance - Kitchen Create

If we have our credentials file configured correctly, a valid subscription ID in our .kitchen.yml and a valid image_urn entry, we’re ready to start up a machine in Azure. To do this we use the kitchen create command. It will take a few minutes to provision.

PS C:UsersStuartPrestonchefazure-ch06> kitchen create              
-----> Starting Kitchen (v1.4.2)
-----> Creating <default-windows2012-r2>...
       Creating Resource Group: kitchen-default-windows2012-r2-20151107T001229
       Creating Deployment: deploy-fc2ef6c5988cb47e
       Resource Microsoft.Network/publicIPAddresses 'publicip' provisioning status is Running
       Resource Microsoft.Network/virtualNetworks 'vnet' provisioning status is Running
       Resource Microsoft.Storage/storageAccounts 'storagefc2ef6c5988cb47e' provisioning status is Running
       Resource Microsoft.Compute/virtualMachines 'vm' provisioning status is Running
       Resource Microsoft.Compute/virtualMachines 'vm' provisioning status is Running
       Resource Microsoft.Compute/virtualMachines 'vm' provisioning status is Running
[...]
       Resource Microsoft.Compute/virtualMachines 'vm' provisioning status is Running
       Resource Microsoft.Compute/virtualMachines/extensions 'vm/enableWinRM' provisioning status is Running
       Resource Microsoft.Compute/virtualMachines/extensions 'vm/enableWinRM' provisioning status is Running
       Resource Microsoft.Compute/virtualMachines/extensions 'vm/enableWinRM' provisioning status is Running
[...]
       Resource Microsoft.Compute/virtualMachines/extensions 'vm/enableWinRM' provisioning status is Running
       Resource Template deployment reached end state of 'Succeeded'.
       IP Address is: 104.40.217.123 [kitchen-c2ef6c5988cb47e.westeurope.cloudapp.azure.com]
       Finished creating <default-windows2012-r2> (9m39.36s).
-----> Kitchen is finished. (9m42.75s)

At the end of the creation process we have a machine running and we are presented its IP address. Test Kitchen stores this in a state file (named .kitchen/default-windows2012-r2.yml in our case) so that later phases can use this information to connect to the machine.

Converging an Instance - Kitchen Converge

Converging an instance simply means bringing the machine toward the desired state so that it can be ready for testing. We have specified the chef_zero provisioner in our configuration file (it’s the default), which means that when we execute kitchen converge the following things will happen:

• The repository and any cookbooks specified as a dependency are transferred to the target machine using the specified transport (WinRM in our case).

• If not installed already, a Chef Client will be downloaded and installed on the machine.

• Chef Client will execute the specified recipes on the machine.

We already have a very basic recipe set up in our repository, which attempts to delete a file. Let’s converge our machine using kitchen converge and watch the output:

PS C:UsersStuartPrestonchefazure-ch06> kitchen converge                
-----> Starting Kitchen (v1.4.2)
-----> Converging <default-windows2012-r2>...
       Preparing files for transfer
       Preparing dna.json
       Preparing cookbooks from project directory
       Removing non-cookbook files before transfer
       Preparing validation.pem
       Preparing client.rb
-----> Installing Chef Omnibus (install only if missing)
       Downloading package from https://opscode-omnibus-packages.s3.amazonaws.com/windows/2008r2/i386/chef-client-12.5.1-1-x86.msi
       Download complete.
       Successfully verified C:UsersazureAppDataLocalTempchef-true.msi

       Installing Chef Omnibus package C:UsersazureAppDataLocalTempchef-true.msi
       Installation complete
       Transferring files to <default-windows2012-r2>
       Starting Chef Client, version 12.5.1
       Creating a new client identity for default-windows2012-r2 using the validator key.
       resolving cookbooks for run list: ["chefazure-ch06::default"]
       Synchronizing Cookbooks:
         - chefazure-ch06 (0.1.0)
       Compiling Cookbooks...
       Converging 1 resources
       Recipe: chefazure-ch06::default
         * file[c:/test.txt] action delete (up to date)

       Running handlers:
       Running handlers complete
       Chef Client finished, 0/1 resources updated in 01 minutes 01 seconds
       Finished converging <default-windows2012-r2> (3m12.08s).
-----> Kitchen is finished. (3m14.35s)

We can see that our recipe executed, and our file was found to be in the correct state (deleted), as seen by the following section:

Converging 1 resources
Recipe: chefazure-ch06::default
  * file[c:/test.txt] action delete (up to date)

No action was taken on our instance because the file did not already exist; therefore the machine was in the desired state as specified by the recipe. We can modify our recipe on our workstation and rerun kitchen converge as many times as we like.

Using InSpec and Kitchen Verify

InSpec is a recently released testing framework, similar to ChefSpec in that it uses BDD-like language constructs in the test specifications. However, InSpec does no simulation of the Chef Client run; instead it tests the actual running state of the machine. This makes InSpec tests a powerful tool for post-convergence automated testing, as we can use it to ensure that each action specified in our recipe has brought the machine to the correct target state. To give a couple of examples, here’s an example test to verify the ‘OS family’ on our target machine is Windows:

describe os[:family] do
  it { should eq 'windows' }
end

Here’s another test that tests whether an Apache configuration has a Listen parameter set to the value ‘443’:

describe apache_conf do
  its('Listen') { should eq '443'}
end

A full list of Resources and Matchers are available at https://docs.chef.io/inspec_reference.html .

As an example test, let’s run a couple of checks on our Windows 2012 R2 machine:

• We’ll check the machine has a DHCP Client service installed, enabled, and running

• We’ll also check that the machine is NOT listening on TCP port 80, as we have not installed a Web Server on it.

Looking at the list of resources, we can see that there are both the Service resource and Host resources available to accomplish this task. So let’s open up the file test/integration/default/default_spec.rb in your text editor and replace the contents with the text below:

describe service('Dhcp') do
  it { should be_installed }
  it { should be_enabled }
  it { should be_running }
end

describe host('localhost', port: 80, proto: 'tcp') do
  it { should_not be_reachable }
end

Once complete, the file should look like Figure 6-12.

Figure 6-12. Inspec example spec located at test/integration/default/default_spec.rb

We can now run kitchen verify to get our test results.

PS C:UsersStuartPrestonchefazure-ch06> kitchen verify                
-----> Starting Kitchen (v1.4.2)
-----> Verifying <default-windows2012-r2>...
..."Test-NetConnection -ComputerName localhost -RemotePort 80| Select-Object -Property ComputerName, RemoteAddress, RemotePort, SourceAddress, PingSucceeded | ConvertTo-Json"
.

Finished in 8 seconds (files took 6.57 seconds to load)
4 examples, 0 failures

As seen from the output, we have 0 failures. Of course this isn’t a real test as if it was a real test we would now add some tests that we expect to pass (perhaps you are looking to define a Web Server on port 80, so it "should be_listening"). The beauty of using Test Kitchen for this is that it is a rapid, repeatable process.

For now, we’ve spent some credit running this VM with a public IP address on Azure and don’t need it any longer so let’s destroy it.

Destroying our Instance - Kitchen Destroy

Destroying our server is as simple as typing kitchen destroy. What is actually happening here is that we are deleting an Azure Resource Group that contains all the resources created by kitchen create. It actually takes some time to acquire locks on all the resources in Azure, so once the delete request has been accepted by Azure, the operation continues in the background, allowing you to continue to the next stage, or to start up a new instance.

PS C:UsersStuartPrestonchefazure-ch06> kitchen destroy              
-----> Starting Kitchen (v1.4.2)
-----> Destroying <default-windows2012-r2>...
       Destroying Resource Group: kitchen-default-windows2012-r2-20151107T001229
       Destroy operation accepted and will continue in the background.
       Finished destroying <default-windows2012-r2> (0m5.58s).
-----> Kitchen is finished. (0m8.95s)

Other Test Kitchen Commands

We covered the basic four stages of Test Kitchen above, but there are a couple of other commands that are useful to know about:

• You can run kitchen test in order to execute all phases of Test Kitchen in order without stopping.

• You can run kitchen diagnose --all in order to diagnose problems with configuration (note: most issues are caused by formatting issues in the .yml file.)

• Finally, instead of running through each test suite and platform sequentially, these can be executed in parallel by running kitchen <command> --concurrency <n> where n is the number of threads you wish to start.