Foodcritic

http://acrmp.github.io/foodcritic/
Chef 専用の静的テストツールで、ChefDK に含まれています。

Cookbook のディレクトリに対してコマンドを実行すると、Foorcritic のルールに違反したコードが検出されます。 

$ foodcritic ./

検出結果にはどのルールに違反しているかがわかるように、ルールの番号が付加されています。
Foodcritic の公式サイトには各ルールの詳細な情報と、修正例が記載されていますので、参考にしてください。

Ruby の静的テストツールを利用

Recipe は Ruby で記述されるので、Ruby の汎用的な静的テストツールを適用することもできます。
たとえば、以下のツールを利用できます。 

Reek

https://github.com/troessner/reek
複雑な Ruby コードを検出する静的テストツールです。

実行方法は Foodcritic と同じです。

$ reek ./

Flay

http://ruby.sadi.st/Flay.html
Ruby の重複コードを検出する静的テストツールです。

これも、実行方法は同じです。

$ flay ./

これらの静的テストツールは開発環境にすでにインストールされていますので、実際に実行して試してみてください。

$ chef gem install <gem パッケージ名>

chef exec <コマンド名>

ChefSpec

https://github.com/sethvargo/chefspec
Chef 専用の動的テストツールで、ChefDK に含まれています。
主に Recipe の DSL が期待通りにコンパイルされているかを確認します。

単純な Recipe の場合、Recipe と ChefSpec のテストコードがほぼイコールになってしまい、
同じことを２度書く手間が増えるだけで、特にメリットを感じませんでした。

現状では ChefSpec は利用していませんし、規模の大きい Cookbook を作らない限りは今後も利用しないと思います。

Serverspec

http://serverspec.org/
サーバーの状態をテストする動的テストツールです。
Chef 専用のものではありませんが、Kitchen が対応していて、標準で利用可能です。
今回は Kitchen から利用することを前提にすすめます。

テストコードの配置

Kitchen で Serverspec を実行する場合、テストコードを決まったパスに配置する必要があります。

まず、テストコードを配置するディレクトリを作成します。

$ mkdir -p ./test/integration/default/serverspec/

※ "default" の部分は .kitchen.yml で指定した suites の name です。

そして、テストコードのファイル名は *_spec.rb とします。

$ touch ./test/integration/default/serverspec/default_spec.rb

※ _spec.rb の前の部分はなんでもいいようです。 Cookbook のテストの場合は Recipe の名前と同じにするのが多い気がします。

テストコードの記述

Serverspec のテストコードはものすごく簡単で、ドキュメント [ http://serverspec.org/resource_types.html ] を見れば一目瞭然です。

たとえば、あるパスにファイルが存在することを確認するには、以下のように記述できます。

require 'serverspec' 
include Serverspec::Helper::Exec
include Serverspec::Helper::DetectOS
 
describe file('/etc/passwd') do
  it { should be_file }
end

Kitchen で Serverspec を実行

Kitchen インスタンスで Serverspec を実行するには、次のコマンドを使用します。

$ kitchen verify

そうすると、Serverspec が自動的にインストールされ、テストが実行されます。
実行結果は以下のようにログに出力されます。

Service "jenkins"    should be running
        
Finished in 0.04041 seconds
1 example, 0 failures