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

3.5 動作のカスタマイズ

渡せるコマンド

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

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'
```

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

spec_helper.rb

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

setproperty: ハッシュを引数として受け取る
```
setproperty { key1: 'value1', key2: 'value2' }
```
property: setproperty にて設定した値を受け取る
```
property[:key1] # 'value1'
```

spec_helper.rb で読み込ませる技

spec_helper.rb

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

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

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

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