機能テスト/結合テストのTestability向上のための定義分割

定義分割をするのは「結合テストのTestabilityの向上」をするためだと思っています。

「インジェクションするセットを一括で変更することにより、環境依存部分を切り離してPOJOだけでテストをできるようにするにし、Testabilityを向上させる」ことが定義分割をするための意味になります。

では、結合テストのTestabilityの向上の観点から分割方法を考えてみます。

コンポーネント分割は、複数のコンポーネントが結合している場合に、複数のコンポーネントを一括で置き換えることができ、コンポーネント単体の結合テストをやるときに役に立つのでありです。

コンポーネント単体での結合テストが簡単に実現できるために、コンポーネント全体の結合テストを実施した際に、どのコンポーネントに問題があるのかの切り分けがしやすくなります。

レイヤ分割は、POJO版、DB版などレイヤの実装を一括して変更することができ、結合テストのTestabilityの向上に役に立つのでありだと思っています。

特にレイヤ分割は、レイヤの実装による影響の問題を切り分けるために有効です。

横断的関心毎の設定に問題があるか、ないかがすぐにわかるようになります。例えば、トランザクション周りの設定のON/OFFを一括で切り替えてテストをすると、トランザクションの設定に問題があるのかないかが、わかるようになります。

また、結合テスト時とリリース時には、横断的関心毎が異なるため、その切り替えをするときにも役に立ちます。例えば、テスト時はDebug用のInterceptor挟みこんだり、パフォーマンス測定用のインターセプターを挟みこんだりします。

開発チームの構成、コンポーネントの構成などにより分割方法は変わるとは思うのですが、

コンポーネントごとにレイヤ分割をすると定義ファイルが爆発するので、結構管理が大変です。さらに、コンポーネント毎の担当者がDIに精通していないといけなくなるため、導入時の説明が結構大変です。

レイヤ分割だけをする場合には、コンポーネント間に依存関係が生まれるため、結合テストのテスタビリティが損なわれます。他のコンポの設定ファイルが間違っていると、自分のコンポーネントが動かなくなったりするので開発しにくいです。