技術とか戦略とか

IT技術者が技術や戦略について書くブログです。

情報処理技術者試験対策「結合テストの進め方(スタブ・ドライバ)」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM
-------------------------------
せっかく単体テストについて書いたので、次は結合テストについて書きます。
主にスタブとドライバについて書きます。
 
結合テストは、モジュール間の整合性を検証するために行います。
モジュール間でインターフェースの実装に相違がないか、業務データの取り扱いに相違がないか、といった所を中心に見ることになります。
モジュール単独の品質が担保されていないと、バグ発生時に原因の切り分けが困難になったり、結合テストで本来検証するべきこと(モジュール間の整合性確認)が検証できなくなったりして工数がかさみますので、単体テストでモジュール単独の品質を担保することが前提になります。
 
連携するモジュールが未完成(単体テストで品質を担保する所まで行っていない)場合は、仮のモジュールであるスタブやドライバを使って当面の間はテストを継続することになります。

  • スタブ
    下位モジュール(呼び出される側)の代わりとなるモジュール。値を返却するだけ等の形で簡単に実装する。
  • ドライバ
    上位モジュール(呼び出す側)の代わりとなるモジュール。処理を呼び出して返却値を表示するだけ等の形で簡単に実装する。

スタブやドライバを作成すれば、連携するモジュールが未完成でも、完成したモジュールから先に結合テストを進めることができます。
スタブやドライバの実装が単純であればスタブやドライバにバグが潜んでいる可能性も低くなるので、バグ発生時にはテスト対象のモジュールに問題があると推測することができ、原因切り分けが容易になります。
 
教科書的には、スタブはトップダウンテスト、ドライバはボトムアップテストで用いられ、トップダウンテストは原因切り分けが容易だが並行してテストを進められない、ボトムアップテストはその逆とされています。
が、実務の上でこのことを意識したことはありません。
ボトムアップテストでもトップダウンテストでも、状況に応じてまとめてテストしたり1つ1つ着実にテストしたりするので)