この記事はgoss advent calender2019参加記事です。
本投稿では、gossテストの再利用性について書いていきます。
ただこの内容については設計要素を含み、必ずしも本投稿のやり方が正解ではありませんが
参考程度の筆者の使っているやり方を書ければと思います。
再利用の重要性
これはgossに限りませんが一度作った物を使いまわすことについて改めて重要であることを書いておきたいです。
何らか動いた結果があれば、それをどこまで変えても動くのか、どこを変えたら動かなくなるのかという観点で調べれば良いため、構築やテストの作業負荷を減らすことができます。
テストツールでの再利用のメリット
手動テストでの再利用は、一度作成したテスト項目一覧(テスト手順と期待結果が書かれたもの)に留まり、テストを実行する場合は都度操作を行う必要があります。
しかしテストツールの場合は、テストの実行をコマンド1回程度で手軽に行えるため、何か気になれば実行したり、1日1回実行しても大した手間にはなりません。
また作成したテストシナリオをファイルで直接別のサーバでテストすることも可能なため、水平分散クラスタのノードのようにIP以外ほぼ同じ構成のサーバでの再利用に留まらず、
例えばOS部分のみ切り出して全体的に再利用したり、httpd部分、DB部分などM/W単位で切り出して再利用することも難しくはありません。
この内容については、gossに限らずserverspecでも同様の内容です。
再利用性の高いテストシナリオについて
gossではgossfileディレクティブを使うことで、別のテスト項目ファイルを呼び出せるため、これを活用して再利用性の高い構成にします。
ここはどういう風に分割するか、などはあくまで一例です。
Hostname1.yaml
Hostname2.yaml
Prod/
Common_OS.yaml
Hostname1_httpd.yaml
Hostname2_httpd.yaml
Common_DB.yaml
Qas/
Common_OS.yaml
Hostname1_httpd.yaml
Hostname2_httpd.yaml
Common_DB.yaml
Dev/
Common_OS.yaml
Hostname1_httpd.yaml
Hostname2_httpd.yaml
Common_DB.yaml
それぞれHostname?.yamlで必要なディレクトリ以下のyamlをgossfileディレクティブでインクルードします。
gossfile:
Prod/Common_OS.yaml: {}
Prod/Hostname1.yaml: {}
Prod/Common_DB.yaml: {}
これらファイルを同期するように各サーバに配置したり、NFSやCIFSでマウントした領域に置きます。
環境ごとでディレクトリを分けていますが、Command等で何か変更をかけるようなことをしていない限りは異なる環境のテストを実行しても問題にならない(Failは出ると思いますが)ため、構成管理優先して一纏めにしています。
テストシナリオ分割時に留意してないこと
これは敢えてですが、テスト項目の重複を容認しています。
これは手動でのテストの場合、重複した内容は作業時間をロスすることになりますが
テストツールでの実行する場合は同じ結果が出るだけで処理時間の延びは容認できるケースがほとんどです。
どうしてもテストシナリオを使いまわししたり、抜け漏れを回避しようとすると重複しがちになりますが、そこは考慮しないと割り切ってテストを構成しています。
もちろん同じ内容を何回も実施しても意味はないため、積極的に重複する必要はありませんが、重複しても大丈夫としておくことで、抜け漏れがないか？という方に注力する方が良いかなと思っています。