本記事はgossテストシナリオ作成 その1の続きです
addコマンドによるテストシナリオ作成
autoaddでは対応できないテストをaddコマンドを使って追記していきます。
goss add command [実行したいコマンド]
上記はcommandの箇所はテストしたい内容を記載します。
テストに応じて、必要なパラメータを指定します。
上記のcommandの例では、実行したいコマンドを指定し、テストシナリオには
goss addを実行した際の結果のexit-code, stdout, stderr などがテストシナリオ化されます。
他にもhttpであればリクエストしたURLへのHTTP response codeなど
dnsであれば名前解決した結果のレコードなどをテストシナリオ化します。
add commandで特に注意が必要なのは実行するコマンド自体がOSに何らか変更を行う場合
それはそのままaddサブコマンドやテスト実行するvalidateサブコマンド実行時に実行されてしまいます。
例えば systemctl stop httpd.service をcommandとしてテスト化した場合
テストの都度httpd.serviceはstopされてしまいます。
goss自体はOSのその瞬間の状態をテストするため、OSの状態を変更した結果を検証したいのであれば、別の方法を用いた方が簡単だと思います。
さらにテストを手動で編集する
出力されたyamlファイルはテキストファイルであるためviなどテキストエディタで編集可能です。
本来期待された結果と異なるシナリオがautoadd/addで作成された場合の修正や
そもそもそれらのサブコマンドでは作成できないテストを記載したりします。
例えばfileのcontains項目には指定パスのファイルにどんな内容が記載されているかをテストすることが可能ですが、autoaddでもadd fileでもその内容は生成できません。
そのため手動でyamlファイルを編集してテストを加えていきます。containsの詳細は別の記事で書きたいと思います。
手動編集時の留意点
一度編集したyamlファイルを対象にautoaddやaddサブコマンドでテストシナリオを追記する場合は注意が必要です。
YAMLは仕様上、コメントを記載することができますが、autoadd/addサブコマンドでファイルを追記するとYAMLコメントを消してしまいます。
gossが一度ファイルを読み込んで追記してファイル出力しなおす弊害です。
他にも同じ内容のテストをautoadd/addサブコマンドで追記したりすると元々書いてあったテストを上書きしてしまうため、テスト作成時はautoadd → add → 手動編集の順にやっていくとスムーズです。
テストシナリオファイル内で別のyamlファイルのテストシナリオを呼び出す
テスト項目にgossfileという内容で特定のgossテストシナリオファイルを指定できます。
これを指定すると既にあるテストシナリオファイルをインクルードできます。
そのため、WebServer.yamlというテストシナリオ内に
gossfile:
httpd.yaml: {}
OSCommon.yaml: {}
PackageCommon.yaml: {}
としておき、それぞれ呼び出すテストを部品化も可能です。これも詳細は別記事でやりたいと思います。
また、部品化が複雑化した場合でも
goss -g WebServer.yaml render
と実行するとすべてのテストシナリオをインクルードした結果のテスト項目を全て表示してくれます。