11回目の Microservices Patterns 読書会に参加したメモ

終わった後の飲み会で注文したローストチキン。勉強会の内容とは関係ない。

簡単な経緯

あまり整理された状態ではない模様。 Testing microservices (Work in progress)

開発チームが実装するテストの話をしたいのは分かる。

テストピラミッドという形式で、レイヤの考え方によりテスト対象を区分けしている。ユニット（ドメインの内部）、インテグレーション（内部と外部のインターフェイス）、コンポーネント（内部と外部のインターフェイス）、E2E（外部）

テストピラミッドの次にコンシューマー駆動契約テスト(CdC)の説明が出てくるあたり、とてもお勧めしたかったことがうかがわれる。読む側には辛い。

パターンとして独立させるくらいには特別視していることがわかる。

後は構成要素ごとにユニットテストとしてどういうテストを書くべきかを説明している。

エンティティやバリューオブジェクトはビジネスロジックが含まれるからしっかりやったほうがよさそう。それはそうだ。

サービスやサーガ、コントローラーやイベントハンドラーはドメイン外部への依存があるからモックオブジェクトが必須になる。外部サービスへの依存を切り離して実行できることに価値があるとするなら、、、まあやってもいいのかな。なんかムダがあるような気がするけどうまく言語化できない。

インテグレーションテストとしてどういうテストを書くべきかを説明している。

persistence integration test はまあ普通に RDB へ保存できることを確認すればよい、そりゃそうだ。

REST エンドポイントの integration test の手法としてコンシューマー駆動契約テストをお勧めしている。 provider team と合意を形成するためのやりとりが発生するので、サービスが無軌道に成長するのを自然に妨げる仕組みだよなぁと思った

最近は1セクションごとに気になるところを確認して、あれば議論するような進行形式になっています。

だいたいこんな感じのやりとりが行われていました。

断片しか記録できてませんが、実際はちゃんと納得できるまで議論されています。

形式をチェックするだけでは物足りない気がする
注文して、注文がキャンセルされて、みたいな一連の流れをどこかでテストするべきなのでは。
- そういう事前状態を宣言した契約をいくつか並べるのでは。
複数のサービスから利用されているため、複数のE2Eを通過させないとリリースできないサービスがある。自律的にリリースできなくて苦しいので、CdCが救済手段になるかもしれないと考えている

テスト通過したら自動でリリースってそんなに一般的？
- 段階的に少しずつ公開範囲を広げるやり方をやってる。
- 内部APIはそうでもないけど、ユーザーの目に触れる改修は慎重に確認してる。
- フィーチャーによってOKとするメトリクスは異なる。

エンティティに定義したロジックで外部サービスを呼び出す必要がある場合の方針に悩んでる。サービスへのアクセサを渡すのかプロキシを渡すのか、呼び出した結果の値を渡すのか？
ビジネスロジックをサービスに定義しがちなので、エンティティに定義するときはどうしてるのか疑問。
エンティティとサービスでは抽象度が合わないので、概念が不足しているのでは？
クロージャを渡してあげるみたいなことをしていることもあった。
イベント原理主義で考えるとエンティティの状態を変更することがなくなるので、テストする意義がなくなってくるなぁ。
状態を型で表現する場合も。

E2Eテストってどうやってるんですか。段階的リリースをしてるからやってない？
- 依存関係も含むテストという意味ではやってます。
- 開発環境で実行したり、テスト環境で実行したり。
デプロイメントを namespace 単位にしてたので、 namespace を跨ぐような依存関係があると困りがち。
このスタイルのユニットテストってムダになりそう。
後になるとUI側のほうが理解できてるからE2Eを書きたくなっちゃう。そうすると頭でっかちになりがちなので悩ましい。
障害事象と同じ抽象度で表現したいときはやはりE2Eを追加したくなる。
個人的な見解だけど、E2Eを補足する低水準テストは書かなくてもいいんじゃないかと思ってる。
脆いこと、実行に時間がかかること、この2点は本当に厳しい。