| 目次 |
|---|
Foodcritic
http://acrmp.github.io/foodcritic/
Chef 専用の静的テストツールで、ChefDK 専用の静的テストツールで、ChefDK に含まれています。
Cookbook のディレクトリに対してコマンドを実行すると、Foorcritic のディレクトリでコマンドを実行すると、Foorcritic のルールに違反したコードが検出されます。
| コード ブロック |
|---|
$ foodcritic ./ |
検出結果にはどのルールに違反しているかがわかるように、ルールの番号が付加されています。
Foodcritic の公式サイトには各ルールの詳細な情報と、修正例が記載されていますので、参考にしてください。Foorcritic の公式サイトには各ルールの詳細な情報と、修正例が記載されていますので、参考にしてください。
Ruby の静的テストツールを利用
Recipe は Ruby で記述されるので、Ruby の汎用的な静的テストツールを適用することもできます。
たとえば、以下のツールを利用できます。
Reek
https://github.com/troessner/reek
複雑な Ruby コードを検出する静的テストツールです。
実行方法は Foodcritic と同じです。 Foorcritic と同じです。
| コード ブロック |
|---|
$ reek ./ |
Flay
http://ruby.sadi.st/Flay.html
Ruby の重複コードを検出する静的テストツールです。
これも、実行方法は同じです。
これは ChefDK には含まれていない、Ruby 全般のツールです。
こういったツールでも、 ChefDK の chef gem install コマンドを使ってインストールし、利用することができます。
| コード ブロック |
|---|
$ flay ./chef gem install reek |
これらの静的テストツールは開発環境にすでにインストールされていますので、実際に実行して試してみてください。
...
chef gem install コマンド でインストールしたコマンドラインツールは、ChefDK の chef shell-init コマンドを実行しておけばそのまま利用することができるようになります。
| コード ブロック | ||
|---|---|---|
$ echo 'eval "$(chefgem install <gem パッケージ名>
chef gem でインストールしたコマンドの実行方法パスを通す場合以下のパスを追加します。
※ たぶん、次期バージョンからは chef shell-init を .bashrc などで実行するようになるかと パスを通さない場合chef exec コマンドを経由して ChefDK にインストールされているコマンドを実行できます。
|
shell-init bash)"' >> ~/.bashrc |
また、そうでない場合も chef exec コマンドを経由して実行することもできます。
| コード ブロック |
|---|
chef exec reek ./ |
| 情報 |
|---|
開発環境にはインストール済みです。 |
Flay
http://ruby.sadi.st/Flay.html
Ruby の重複コードを検出する静的テストツールです。
これも、実行方法は Foorcritic と同じです。
| コード ブロック |
|---|
$ flay ./ |
このツールも Ruby のものなので、利用するには chef gem install コマンド でインストールします。
| 情報 |
|---|
開発環境にはインストール済みです。 |
ChefSpec
https://github.com/sethvargo/chefspec
Chef 専用の動的テストツールで、ChefDK 専用の動的テストツールで、ChefDK に含まれています。
主に Recipe の DSL が期待通りにコンパイルされているかを確認します。
単純な Recipe の場合、Recipe と ChefSpec のテストコードがほぼイコールになってしまい、
同じことを２度書く手間が増えるだけで、特にメリットを感じませんでした。
現状では ChefSpec は利用していませんし、規模の大きい は利用していませんし、よほど規模の大きい Cookbook を作らない限りは今後も利用しないと思います。
Serverspec
http://serverspec.org/
サーバーの状態をテストする動的テストツールです。
Chef 専用のものではありませんが、Kitchen 専用のものではありませんが、Kitchen が対応していて、標準で利用可能です。
今回は Kitchen から利用することを前提にすすめます。
テストコードの配置
Kitchen で Serverspec を実行する場合、テストコードを決まったパスに配置する必要があります。
まず、テストコードを配置するディレクトリを作成します。
...
※ "default" の部分は .kitchen.yml で指定した suites の name です。
そして、テストコードのファイル名は *_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 が自動的にインストールされ、テストが実行されます。そうすると、Serverspec が自動的にインストールされ、テストが実行されます。
実行結果は以下のようにログに出力されます。
| コード ブロック |
|---|
Service "jenkins" should be running
Finished in 0.04041 seconds
1 example, 0 failures |
| 情報 |
|---|
kitchen verify のほかに、kitchen test コマンドも存在します。 |
...
通常 kitchen test ではインスタンスの起動からテストの実行、インスタンスの破棄までを一気に実行します。 |
テストができたら
ここまでで第２回のハンズオンは終了です。
次のページ では開発環境を作るときに使用した Vagrant の基礎的な部分を紹介しています。
興味のある方は参考にしてください。