2024.07.24
「スタブ」は、ソフトウェア開発を効率的に進めるために広く活用されています。しかし、スタブの概要や活用時の注意点を把握していない方も多いのではないでしょうか。
今回は、ソフトウェア開発で使われるスタブとは何か、ドライバやモックとの違いについても基本からわかりやすく解説します。
また記事の後半では、スタブの活用例やメリット、注意点も紹介するので、ぜひ最後までご覧ください。
- もくじ
1．スタブとは？
「スタブ」とは、上位のモジュール（プログラム要素）から呼び出される下位モジュールを疑似的に再現する代替品のことです。
テストにおいて、下位モジュールが未完成のために、上位モジュールを動かせないケースが往々にしてあります。この時、下位モジュールの役割を疑似的にカバーしてくれるのがスタブです。
たとえば、一覧表示機能をテストしたいものの、内部で呼び出すデータ取得モジュールが未完成だったとします。この場合、ダミーデータを提供するスタブを作り、データ取得を再現することで、一覧表示機能の動作を確認できるでしょう。
なお、スタブは「切り株」などを意味する英語のstubに由来します。「根幹部分が抜けている」といったニュアンスから、スタブと呼ばれるようになりました。
2．スタブの特徴
スタブは「関数」や「メソッド」のように、部品化されたプログラム要素として定義されることが一般的です。関数名や引数の構成、戻り値のデータ型などは、基本的に完成版の下位モジュールに合わせます。
また、渡されたデータに合わせて上位モジュールが期待するデータを返します。外部から見た振る舞いは、可能な限り本来の仕様に合わせなければなりません。あくまで疑似的な再現のため、データベース接続といった本番環境向けの処理は省略可能です。
2‐1 スタブの主な用途
スタブの主な用途は、上位モジュールのテストや簡易的な動作確認です。
つまり、ソフトウェアを動かしたいものの、通過点のモジュールが未完成の場合の穴埋めとして用いられます。
また、開発するソフトウェアの大まかなイメージを形にするために、プロトタイプ（試作品）の制作段階でスタブを用いるケースもあります。
2‐2 ドライバとの違い
ドライバとは、下位モジュールを呼び出す上位モジュールを疑似的に再現する代替品のことです。
いずれも代替品ですが、ドライバは「呼び出す側（上位モジュール）」、スタブは「呼び出される側（下位モジュール）」を代替する違いがあります。
テスト対象のモジュールを動かす際に活用できる点は、ドライバもスタブも同様です。ドライバはテスト対象へデータを送って動かしますが、スタブはテスト対象からデータを受け取って動作します。
2‐3 モックとの違い
モック（mock）には英語で「疑似」「偽の」といった意味があり、スタブと同様に下位モジュールの代替品です。
ただし、モックとスタブでは利用の目的が違います。スタブは前述のように「上位モジュールを動かすため」に使われる一方、モックは「上位モジュールの出力を検証するため」に使われます。
たとえば、上位モジュールがデータリストを出力し、下位モジュールに渡すとしましょう。
この時、上位モジュールが出力したデータリストが妥当かを検証するために、下位モジュールを疑似的に再現するのがモックです。
モックは広い意味ではスタブの一種といえますが、基本的にテストコードのように使われます。
3．ITエンジニアがスタブを活用するメリット
スタブは単なる代替品と思われがちですが、明確なメリットがあります。
ITエンジニアがスタブを活用するメリットは、主に次の3つです。
3‐1 ソフトウェアの動作を早期に確認できる
スタブを活用することで、テスト環境を簡単に構築できるので、ソフトウェアの動作を早期に確認できます。
ソフトウェア開発において、「下位モジュールが未完成のために動かせない」といったケースもあるでしょう。
しかし、動作確認を後回しにすれば、下位モジュール完成後に動かして初めて致命的な欠陥に気づく可能性があります。スタブで仮置きすれば、下位モジュールが未完成でも上位モジュールの動作を確認できるので、問題を早期に発見でき手戻りを抑えられるでしょう。
また、スタブによってプロトタイプを制作すれば、早期に顧客へイメージを伝えられます。
3‐2 チームでの分業がしやすくなる
スタブを活用することで、上位モジュールと下位モジュールの作成を分業しやすくなります。
1つのソフトウェアを複数人のチームで開発する場合は、「自分が上位モジュールを実装し、他メンバーが下位モジュールを実装する」といったように、分業して進めることがあるでしょう。
その場合、下位モジュールの完成が遅れてしまい、上位モジュールのテストも遅れてしまう懸念があります。
スタブで下位モジュールを仮置きすれば、他メンバーの完成を待たずして自分のモジュールをテスト可能です。このようにスタブを活用すれば、分業に際して生じる「完成待ち」の時間を減らせます。
3‐3 実装のハードルが低い
スタブは、複雑なロジックやデータ構造を扱わなくても実装できるケースが多いため、活用しやすいというメリットもあります。
前述のとおり、スタブを活用することで、データベース接続といった外部とのやり取りを省略できます。
スタブは、引数や内部データに応じたデータを返すだけの関数でも、テスト対象モジュールの動作を模倣し、テスト環境の構築が可能です。
なお、スタブを用いてテストを行う場合は、実施条件や実施手順などをテストケースに正しく記載する必要があります。
テストケースの作成時には、当サイト「Qbook」が提供するテストケースのテンプレートをご活用ください。無料会員登録を行うだけで、ダウンロードが可能です。スタブをテストケースへ組み込む際に整理しやすくなるでしょう。
テストドキュメント テンプレート
ISO/IEC/IEEE 29119（以下、29119規格）に対応したテスト計画に関するテンプレートを公開しています。「テスト計画」とは、テストの設計、実装、実施、管理といった、テストのすべての指針を定めるものです。ぜひ、実務での計画立案にご活用ください。
4．ソフトウェア開発におけるスタブの活用例
ここでは、ソフトウェア開発でスタブを活用するイメージをつけられるよう、開発手法の1つである「TDD（テスト駆動開発）」での活用例を紹介します。
TDDとは、実装予定のプログラムを検証できるテストコードを先に作成し、それを利用しながら開発を進めていく手法です。
TDDの大まかな流れは、まず初めにテストケースを作成し、それに合うようにコードを作成していきます。
最初は本番のプログラムが未実装のため、テストコードの実行結果はNG（レッド）となります。実行結果がOK（グリーン）となるように最低限のプログラムを作り、改良（リファクタリング）を重ねて完成品に近づけていきます。
スタブは、TDDにおける「レッド→グリーン」の工程で広く活用されます。つまり、下位モジュールをスタブで仮置きすることで上位モジュールの処理をカバーし、テストコードをOKにするのです。なお、TDDについて詳しくは、次の記事をご覧ください。
5．ソフトウェア開発にスタブを取り入れる際の注意点
スタブは便利ですが、注意点もあります。ソフトウェア開発にスタブを取り入れる際の注意点として、次の3つを把握しておきましょう。
5‐1 完成品を100％再現できるわけではない
前提として、スタブは完成品を100％再現できるわけではありません。特に、外部との通信などを省略するため、タイミングに実際とのずれが生じる可能性が高いです。
上位モジュール全体の流れを確認する際には役立ちますが、本番環境と完全に同等のテストは行えません。そのため、スタブでは再現しきれない部分があることを念頭に置きましょう。
5‐2 実装に工数がかかる場合がある
スタブの実装に工数がかかる場合もあります。スタブを実装する際、下位モジュールの仕様や設計を確認し、振る舞いを再現するコードを考えなければなりません。
未完成の下位モジュールが多かったり、仕様や設計が複雑だったりすると工数は増大します。
スタブの実装に多くの工数をかけてしまえば、「上位モジュールの動作を早期に確認できる」というメリットが薄れてしまいます。あまりに工数がかかりそうな場合は、別モジュールの実装を先行着手する、など代案を考えるべきでしょう。
5‐3 結果を信用し過ぎない
スタブを用いて実施したテストの結果を信用し過ぎないことも大切です。
前述のように、完成品と100％同等の動作を確認できるわけではありません。スタブでのテストはOK判定でも、完成品ではバグが顕在化するケースもあります。
また、スタブ自体の実装に不備があれば、当然ながらテスト結果も信用できません。スタブを取り入れる際には、100％正しいとは限らないことを念頭に置きましょう。
まとめ
スタブとは、上位のモジュールから呼び出される下位モジュールを疑似的に再現する代替品のことです。
スタブは実装のハードルが低いことが多く、活用することでソフトウェアの動作を早期に確認できます。
しかし、スタブで完成品を100％再現できるわけではありません。スタブをソフトウェア開発で活用する際には、メリットや注意点を十分に把握し、適切に取り入れましょう。
なお、スタブ以外にもソフトウェア開発に関するノウハウを学びたい方は、当サイト「Qbook」をご活用ください。
Qbookの無料会員登録を行えば、イベント情報や業界人のインタビューなど、最新のお役立ち情報をメールマガジンで受信できます。
