テストピラミッドにおける結合テストについて
テストピラミッドにおける結合テスト部分について
結合テストの種類
テストピラミッド内では、結合テストと一括りにされているが、結合テストの中にも種類があり異なる性質を持つ
- DBやファイルへのアクセス等の共有依存がない結合レイヤーに対する自動テストであれば、テストは高速に稼働する
- 共有依存があるレイヤーに対する自動テストであれば、テストは遅くなる
- ※ mockやstubを使わないケースを想定
何が言いたいのかというと、共通依存がない結合レイヤーのテストは、単体テストと同じ性質を持つ為、テストピラミッドの真ん中ではなく一番下に位置するのでは？という事
具体例を交えつつ考えてみる
- 共有依存が3つあるケース
- Workerを起動した後、DBを見にいき、抽出したデータをCSVに書き込むコードのテスト
どこをmockするんだよ、みたいない意思決定も必要だし、まあ面倒くさい。多分もっさりしてるだろうね。
- 共有依存がないケース
- 差分を計算して、差分を整形して、差分の結果をデコレートするコードのテスト
コード自体複雑かもしれないが、共有依存がない分、何も考えなくてもテストコードが書けるし高速に稼働する
共有依存の数に注目する
下みたいにテスト対象コードが持つ共有依存の数に注目したらバランス良くテストを実装できないだろうか
共有依存が2つあるレイヤーのテストコードの数 < 共有依存が1つだけのレイヤーのテストコードの数 < 共有依存が0のレイヤーのテストコードの数
共有依存の数を指標に置いてあるので、E2Eも一番上にくるし、ある程度はテストピラミッド通りになる
このモデルに従うメリットを紹介する
共有依存が少なくなるようにコードを書く為には、各コードの責務を細かく分割して実装する必要がある
責務毎にまとめられたコード群は凝集度が高くメンテナンスしやすい
つまり、負債になりにくく可読性も高いコードになる
このようなコードが増えると、開発生産が向上し、より多くの機能をリリースできる体制が手に入る
