Cookbook Testing With TravisCI


I work, on a daily basis, with a six member team on awesome Chef cookbooks. All of the team members can write code for the cookbooks and with this code, change the behaviour of the managed infrastructure.

All this change makes it very important to use syntax and style checks with integration testing. We want to be as sure as possible that a git push doesn’t break the infrastructure.

All our software projects are tested on each push to Github, so I’d like to see the same behaviour for testing the cookbooks.

To demonstrate I’ll use a cookbook I’ve created for this blog blog_cookbook.

Basic setup

I use bundler to manage the gems with a Gemfile. If you haven’t installed Bundler yet, please do so with gem install bundler We generate a Gemfile by running bundle init. This command will generate a basic Gemfile for us.

source "https://rubygems.org"

gem 'rake'
gem 'chef', '~> 12.0'
gem 'foodcritic'
gem 'rubocop'

By using the above Gemfile you have all the nessesery dependencies to follow along with this post. You can install the gems by running bundle install.

Checking the syntax

As a first test we need to validate the basic code is correct. Chef is providing this functionality with the command-line tool called knife.

Knife will be available if Chef is installed on your system. If you don’t have Chef installed yet I recommend to install it with the ChefDK. To test if you have knife available you can run knife --version. This will return the version of Chef that is installed on your system.

If knife is available we can run the syntax check with the following command.

-> knife cookbook test blog_cookbook
checking training
Running syntax check on blog_cookbook
Validating ruby files
Validating templates

Lint checking

To validate if we followed the community guidelines I like to run Foodcritic. On the website the creator explains that Foodcritic has two primary goals.

  • To make it easier to flag problems in your Chef cookbooks that will cause Chef to blow up when you attempt to converge. This is about faster feedback. If you automate checks for common problems you can save a lot of time.

  • To encourage discussion within the Chef community on the more subjective stuff - what does a good cookbook look like? Opscode have avoided being overly prescriptive which by and large I think is a good thing. Having a set of rules to base discussion on helps drive out what we as a community think is good style.

To run Foodcritic use to following code

-> foodcritic -f any .

This command checks the current (.) folder against the rules and returns a error if there are any matches. If you get no output everything is good!

Pro tip The great people at Etsy have made there custom rules open so we can use there expertise. Check them out on the Github repo

What about Ruby?

Where Foodcritic only focusses on specific Chef problems Robocob takes on Ruby style and syntax. On the Github page you can check all the rules Robucop checks for. Its a quite extensive list.

While some people think Rubocop is way to strict when you only work with Chef. I believe following the Ruby community style works great when developing cookbooks with a medium to large team or with a team that has limited experience with Ruby development.

Enforcing style ensures every team member the code looks as expected and there is no personal style in the cookbooks.

Testing the actual converge