継続的デリバリー 「第7章 コミットステージ」「第8章 自動受け入れテスト」 感想

『継続的デリバリー』の感想第２回です。前回はこちら。

【送料無料】継続的デリバリー [ ジェズ・ハンブル ] 価格：3,990円（税込、送料込）

コミットステージ

コミットステージではCIツールなどで一通りのユニットテストが実行され、
問題なければバイナリが作成されます。
これは今のチームではかなりの品質でできています。

細かい問題を挙げると、10分前後の時間がかかっているため比較的長いことと、
プロダクト全体のカバレッジが高すぎて、一部カバレッジの低い箇所があっても気づきにくくなっていること。
後者はカバレッジの見せ方を工夫することで解決可能だと思いますが、これはおいおい考えなくてはならないポイントかと思っています。

自動受け入れテスト

コミットステージのあとは、受け入れテストステージに移行します。ここからが今回の本題。

【What】　受け入れテストって何？

ここで行われる「受け入れテスト」は、
個々で見ると、機能要件や非機能要件など、各ストーリーの要求が満たされたかを確認するテストです。
ユニットテストがあくまでデベロッパの設計どおりに動いたかをテストするのに対し、こちらは、そもそもの要件にあっているかをテストすることになります。

【Where】　どこで実行されるの？

受け入れテストは、アプリケーションをユーザー受け入れテスト（UAT)環境においたうえで実施される
と第4章で述べられています。
なので、コミットステージで作られたバイナリが、テスト環境（本番ではない）にデプロイされて、テストが行われることになります

【How】　どうやって実行するの？

本の中ではツールとしてCucamber系とxUnit系の2種類が紹介されていました。ケースによって使い分けろとのこと。
（でもxUnitだと、デプロイしないでの実行になりますよね、、、？）

開発者としてはユニットテストと同じツールで実行可能なxUnitを使ったテストは作成が便利で、実際私のチームの一部のプロダクトはJUnitで受け入れテスト的なテストも記述しています。
これの問題点はデプロイの検証ができないこと。
なので、今後は、HTTP経由でのテストに移りたいなぁと思っているところです。

また、外部のシステムに対しては、先方への負荷が大きいようなら、スタブなどを使って仮想化すべきとのこと。
この場合は、月に一回とか週に一回のように、頻度を落とし、
「コミットステージの後ろではないところ」で実行するのがいいようです。

【送料無料】継続的デリバリー [ ジェズ・ハンブル ] 価格：3,990円（税込、送料込）