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

3.5 動作のカスタマイズ

• Specinfra.configration を利用して、serverspecの動作をカスタマイズできる
• set メソッドは、Specinfra.configration のシンタックスシュガー

渡せるコマンド

使えるコマンドを解説した公式のドキュメントが見つからない...

• ssh_options: Net::SSH.start に渡すオプション
• pre_command: テスト実行前に引数のコマンドを実行

• env: 環境変数。hash で複数渡せる

  set :env, :LANG => 'C', :LC_MESSAGES => 'C'
  

• path: PATH

• shell:テストで使用するシェル

• sudo_path: sudo する時のpath

• disable_sudo: テスト実行時に sudo しない

• request_pty: PTYを常に要求

  • 標準エラー出力と標準出力が一緒になるので注意
  • Execバックエンドの場合も同様
    • 1.8.7の互換性のため

• sudo_options: sudoする時のオプション

  set :sudo_options, '-u foo'
  

3.6 一時的な動作の変更

let: 一時的なset

describe command('whoami') do
  let(:disable_sudo){ true }
  its(:stdout){ should match /foo/ }
end

Rspec の around を使う

Rspec.configure do |c|
  c.around :each, sudo: false do |example|
    set :disable_sudo, true
    example.run
    set :disable_sudo, false
  end
end

sudo: false のあるExampleでのみ disable_sudo が有効になる

describe command('whoami'), sudo: false do
  let(:disable_sudo){ true }
  its(:stdout){ should match /foo/ }
end

3.7 specファイルを複数のホストで共有

• Rakefileで使用するspecを制御できるのでやりようは自由

• こんなふうなやり方もあるよという提案

• ロール毎にまとめる

  • 共通のテスト、dbサーバ、appサーバ用のテストをそれぞれ用意
  • Rake でサーバ名毎に、どのテストを実行するかを決める

• モジュール毎にまとめる

  • chef なら cookbook単位
  • 各 cookbookにspecディレクトリを用意
  • それを読む
  • サーパ構成管理ツールを乗り換える時に大変
  • attributeとかを多用しているとできなさそう

• この辺はプロジェクトに応じていろいろやりようがある気がする

3.8 ホスト固有情報の利用

• setproperty: ハッシュを引数として受け取る

  setproperty { key1: 'value1', key2: 'value2' }
  

• property: setproperty にて設定した値を受け取る

  property[:key1] # 'value1'
  

サーバ毎の固有の設定を json 書く

spec_helper.rb で読み込ませる技

set_property JSON.perse(File.read('properties.json'))[ENV['TARGET_HOST']]

3.8 もそうだけれども、やりようは色々あるから、自由にやってね! というスタンスを感じる

3.9 任意コマンドの実行

テスト実行前に任意のコマンドを実行したい場合

• Specinfra::Runner に色々なコマンド実行用メソッドがある
  • Q: 使えるメソッドの一覧どこ
• Specinfra::Runner.run_command で任意のコマンドを実行
• Specinfra::CommandResult オブジェクトが返る
  • success?
  • failure?
  • stdout
  • stderr
  • exit_status

3.12 テストコード実装の指針

• 新規システム
  • 最初は書かずに、ある程度固まった所で書く
  • 寿命が短いシステムはわざわざテストしなくても良い
  • リファクタリングのためにテストは必要
• 既存システム
  • テストがない場合、今後も長く使うのであれば書く
  • システムは変わるもの。変えるときにテストがあると安心
• 構成管理ツールがある場合
  • そのモジュールやcookbookが何をするものかを明示するため
  • 構成管理ツールは信用する。インフラコードを書く人間を信用しない
    • ツールの設定をする人が間違えたり、勝手に(別の所で)バージョンが変わっていないことを保証する
• どこまでテストするか?
  • サーバのとしての役割が必須な所まで
  • 設定ファイルの詳細まで追うのは苦労の割に実入りが少ない
  • 設定そのものよりも、設定によってもたらされる振る舞いをテストすべき
    • それは serverspec 外の仕事 → 例: Infratester
  • セキュリティ上重要な部分
• インフラコードの変更、パッケージ/OSのアップデートで想定しない状態になるかどうかを確認する
  • そのために必要なことは何か?