オライリーのServerspec本のどくしょかんそうぶんです

1章 Serverspecの紹介

Serverspec : サーバの状態をRspec記法のコードにより自動的にテストするためのツール
利用目的
- TDDによるインフラコード開発
- サーバ構築後の確認作業の自動化
- サーバ監視に使う人も居る → そんな人もいるのか
- サーバのあるべき状態の抽象化
本質 : テスト駆動によりインフラコードの開発やリファクタリングを促進する
必要性
- TDDで、infrastructure as code を進めるため
- サーバの状態をServerspecが保証することで、リファクタリングがやりやすくなる
開発の哲学
- 導入の敷居を下げる
  - Ruby1.8.7をサポート → RHEL6系でデフォルトのRubyであるため
- 特定のサーバ管理ツールに依存しない
  - 構成管理ツールのライフサイクルより、テストコードのライフサイクルの方が長いであろうという哲学
- 1つのことを上手くやる
  - サーバのテストをやるだけ → 複雑で多機能なツールは使われづらい
  - 並列実行はRakeに任せている
究極の目標
- システムの継続的改善に寄与すること

2章はじめてのServerspec

serverspec-init はサンプルコードを生成するだけで、実践向きではない
- あくまでサンプル
Rakefile
- テストの実行に必須ではない
- ただし、Serverspecは1つのプロセスで複数のホストを扱うことを考慮していない
- Rakeを利用してホスト毎にタスクを分ける
spec_helper.rb
- Rspecと同様に、serverspecの挙動を制御する

3章 Serverspecの本格利用

あえて expext ではなくワンライナー should 記法を推奨している
- 最も直感的にかけるため
- テストが通ったか、通らなかったか? だけを求めているので自然言語風に記述にこだわりがない
- shouldだけ覚えていれば使えるようにしたい
- Rspecの記法のバリエーションの隆盛に振り回されたくない
  - わかる
- ちなみにRspec3で非推奨になるのは　Object#should でワンライナー should 記法は残る

.rb

describe packege('nginx') do
  it { should be_installed }
end

3.2 リソースとリソースタイプ

.rb

describe packege('nginx') do
  it { should be_installed }
end

リソース : 具体的な個別テストの対象

上記の場合 packege('nginx') がテスト対象となるリソース

リソースタイプ : リソースの種類

上記の場合 packege('nginx') リソースのリソースタイプは、 packege

ServerspecではSSH経由でテストを実行する場合、デフォルトで sudo をつけている

3.4 テスト対象ホストの追加

serverspec-init で生成される Rakefile では以下のように設定している

.rb

namespace :spec do
  targets = []
  Dir.glob('./spec/*').each do |dir|
    next unless File.directory?(dir)
    target = File.basename(dir)
    target = "_#{target}" if target == "default"
    targets << target
  end

spec以下のディレクトリ構成はこんな感じ

$tree
.
├── spec_helper.rb
└── #{サーバ名}
    └── sample_spec.rb

なので、テスト対象のホストを増やしたい時は、spec 以下にサーバ名のディレクトリを増やせば良い
また、Rakefileの当該部分を書き換えることで、別の方法でテスト対象を増やすことも可能
- 例えば AWS の API を叩くとか、consulを使うとか

1章 Serverspecの紹介

2章 はじめてのServerspec

3章 Serverspecの本格利用

3.2 リソースとリソースタイプ

3.4 テスト対象ホストの追加

2章はじめてのServerspec