コンポーネントテストのお話

はじめに

前回、ここでテスト自動化の投稿をしたので、
続きとして書いてますが、おそらく単一投稿として読めるかと思います。
単体テストの話と重複する部分が多いので、書いてないことはそちらを見てもらえればよいかなと思います。
さして内容はないです、えへへ。

コンポーネントテストとは

場所によって呼び方変わるかと思いますが、いわゆる結合テストの位置付けのもの。
チーム開発の場合、自分たちの結合テストが何を担保するのか、話し合ったほうがいいでしょう。
逆に、それ以外に関しては単体テストと基本同じだと考えてます。
さて、結合テストの担保範囲はおそらく以下の5パターンが考えられるのではないでしょうか。

1. プロダクトコード内部のインタフェース間の結合
2. プロダクトの構成要素(e.g. DB)との結合
3. 別組織/別ベンダのプロダクトとの接続部分
4. 外部公開する機能のインタフェースの動作確認
5. 複数クラスを組み合わせて実現される機能の動作確認

1, 2, 3が接続の確認であるのに対して、4, 5は意味ある1機能と見なしてテストする点で異なってますね。
4はAPIのテストをイメージしてもらえれば良いかなと。
ちなみに、実践アジャイルテストで紹介されていたテスト自動化のピラミッドにおける
コンポーネントテストもおそらくこの5つ目のことではないかと思います。
各プロジェクトの性質や組織文化にあった定義を使うかITa、ITbみたいに複数使い合わすのが良いかなと思います。

ただし、3つ目はやりすぎると(自分たちの責任の範囲外の)他プロダクトの検証になりかねないので注意が必要です。
他プロダクトのSLAや、自分たちのプロダクトに要求される品質レベルを鑑みて判断するのも良いですし、
あとは、自分たちのプロダクトと外部ベンダのプロダクトの責任範囲を明確化する意味で検討自体はしても良いかもしれません。

参考

http://endok.hatenablog.com/entry/2014/06/08/215043
実践アジャイルテスト