puppetでLAMP構成を構築する part4

前回puppetizeしたphpをServerspecでテストしてみたいと思います。

はじめに

前回・今回の記事では「puppetize」→「Serverspec」の順で作業してしまってますが、本当は、テスト駆動開発の考えかた的に「Serverspecでテストケースを記述」→「puppetize」の順に進めたほうが望ましいです。
少しだけ具体的に言うと、「先にあるべき姿を持った上でテストケースを記述(Serverspec)し、それを満たすように実装(puppetize)をする」という流れですね。
次回以降（mysqlなど）は、この順序で進めたいと思います。

テストの記述

前回のpuppetizeでは、以下をpuppetizeしています。

1. epelリポジトリの追加
2. remiリポジトリの追加
3. phpのインストール
4. php.iniの配置

なので、各々をServerspecでテストしましょう。
テストコードはこんな感じです。
特にクセのある記述はないので、解説は省略します。

$ cat spec/WEB01/php_spec.rb
require 'spec_helper'

# 1. epelリポジトリは存在するか
describe yumrepo('epel') do
  it { should exist }
  it { should be_enabled }
end

# 2. remiリポジトリは存在するか
describe yumrepo('remi') do
  it { should exist }
  it { should be_enabled }
end

# 3. パッケージがインストールされているか
describe package('php') do
  it { should be_installed }
end

# 4. php.iniは配置されているか
describe 'php.ini' do
  describe file('/etc/php.ini') do
    it { should be_file }
  end
end

あとはテストを実行してみましょう。

$ ASK_SUDO_PASSWORD=1 bundle exec rake spec:WEB01
....
Yumrepo "epel"
  should exist
  should be enabled

Yumrepo "remi"
  should exist
  should be enabled

Package "php"
  should be installed

php.ini
  File "/etc/php.ini"
    should be file
....
Finished in 6.09 seconds (files took 2.55 seconds to load)
○○ examples, 0 failures

php.iniの記述内容をテストしたい場合

php.iniの変更は行ってないので、今回はphp.iniの記述内容のテストは省略しています。
もしテストしたい場合、inifileを使ってテストすることをお勧めします。
GitHub - TwP/inifile: Native Ruby package for reading and writing INI files

its(:content) { should match(/****/) }でも記述はできますが、コメント行に同じ記述があるなどした場合、それを拾ってテストが通ってしまう場合などがあります。

例）its(:content) { should match(/short_open_tag = On/) }の場合
以下のような記述もOKになってしまう。

...
; short_open_tag = On
short_open_tag = Off
...

正規表現の^や$を活用すればshould matchでも記述できるといえばできますが、=の間の空白有無も考慮して書くなど少々面倒です。
そういった意味でもinifileの方がオススメです。
詳しくは次回解説したいと思います。

---