第7章 テスト
複数のマイクロサービスから成り立つサービステスト、統合テストにどう立ち向かうか。という話し。
古典的な単体自動テストから話しは始まるんだけど、単体テスト - サービステスト(サービス間の結合) - エンドツーエンド(UI上から稼働テスト)と上流に向かって話しが進んでいきます。
この章では特にエンドツーエンドに焦点を当てて解説されていた。
特に結合するサービスに後方互換のないAPI変更なんかが入った場合、単体テストでモックAPIなんか使ってた場合、フェイルキャッチが遅れてしまう場合もある。なので特にマイクロサービスにおいては上流のテストも大事だと思っている。
エンドツーエンドの問題点
エンドツーエンドはアプリケーション動作に一番、自信を得られるフェーズなんだけど、マイクロサービスの集合としてテストを行うには色々な問題点があるとのこと。
読んだ印象では
- テスト時間が長くなりフィードバックまでが間延びしてしまう。
- 複数のサービスの状態次第でフェイルになったり、これは本書では触れていなかった？と思うけど、フェイル時の境界分けの発見のしづらさ。
- 多数のサービスからなるテストの際、各々のサービスが時間経過でチェックインされていく複雑性。
のような問題点を感じた。
で、本書では、エンドツーエンドのテスト"数"を減らしていこうよ。減らす基準は？なんてことやサービス間での"契約"を決めておこう(ODCというらしい)という手法をツールの紹介も踏まえて解説しています。
そしてそして、時にはチーム間での対話も有効だよね。
「契約」とは？
サービス間でのインターフェースの取り決めをmeta化しておく。
CI時にそのmeta情報と実際のサービスのインターフェースを確認すれば良い。
契約と異なるインターフェースがビルドされた場合、契約に基づいて原因と影響するサービスなんかが把握できる。という手法。
なので「契約」はあるサービスがアップデート時に勝手に更新される可能性がある(笑)ので、各サービスごとに下流への結合点の契約を持っておくべきかな。
この「契約」はコンシューマ(使う方のサービス)しか変更できないみたいな。使われる方が勝手に更新しちゃうと意味をなさなくなる。
スモークテスト
これは結構みんな意識せずにやってる人もいるとは思うんだけど、デプロイの後、すぐにリリースせずに稼働中サーバなんかでリリース待機するみたいなの。
副作用のないサービスなんかは、本番環境でテストできる。
そして、旧バージョンも一定期間同居させることでフェイル時の切り戻しを簡易に行うことができる。僕なんかはよくシンボリックリンクを切り替えて、デプロイ後のリリースとかしてたなあ。
こんな感じ。
release/ -> ./rev100.product/ rev100.product/ rev101.product/
