モジュールの実装・単体テスト

分担

モジュール化が一段落したら，分担を決めましょう

一つのモジュールを2〜3人で担当できればベストです．

確認

モジュール毎に，担当者は，

やるべき事とインタフェースを確認し，
プログラム化を参考に，まずは関数プロトタイプ（名称，機能，何を引数で受け取って何を返すか）を作成してみましょう
- モジュール（オブジェクト）に持たせる「メソッドとしての」関数を考えます
- どのモジュールからも利用できそうな汎用性の高い機能は，共通の関数として格上げしましょう

モジュール内部説明

担当者は，モジュールの実現（実装）方法について考えましょう

インタフェースを作る側から考えましょう
インタフェースを提供するための関数の実現を考えましょう
インタフェースに書かれていない内部変数や関数が必要か検討しましょう

それらを，モジュール内部説明書（仕様書）としてまとめましょう．

モジュール内部説明書（仕様書）の作成

まずはモジュールが提供するインタフェースを確認し，

何を受け取って（入力），何を返すのか（出力），または，何を行うのか，

を明確にしましょう（インタフェースの定義と説明）．

続いて，モジュールが提供するインタフェースの実装方法を書きます．関数内部の操作を，モジュールが提供する概念（の詳細）と機能（の詳細）を用いて記述します．（実装方法に記述した内容を，実装言語で翻訳し直したものがそのままソースプログラムになると理想的．）

仕様書を作る意味

実装まで考えずに作成した提供インタフェースが，妥当であるか確認する目的
データ構造が妥当であるかを確認する目的
ある関数が実行されるために必要な状態の確認（どんな引数が必要なのか?）
ある関数が実行されたあとの状態の確認（どんな変化が起きるのか?）

部品作り

モジュールの簡単なプロトタイプを作ってみましょう．

インタフェース仕様を満たしているもので，
まずは関数の入口と出口を作ります．
徐々に中身を入れていってもいいし，作りなおしてもいいです．

あるいは，

モジュールを実装するための，
ごくごく小さな部品を，
動作確認しながら作っていきましょう．

得られる成果（または目的）

実装のための基本的な考え方や技術が身につきます
自分（達）でできる，という自信が得られます
作ろうとしているものを実感できます
作ろうとしているものとプログラムを対応付けられるようになってきます

単体テスト

ある程度モジュールが出来上がってきたら，モジュールが提供する機能をテストすることが重要です．主な目的は，バグを検出して修正することであり，関数の機能や，モジュールの機能だけをテストするメインプログラムを作ることが有効です．

このテストは，モジュールを作成した本人が担当すべきであり，技法としてはホワイトボックス法などが使われます．

担当者ごとに，ひとつひとつの関数やモジュールの機能をテストしましょう．

テストの意義

（書籍『経験ゼロでもできるプログラミング現場の単体テスト』より）

中規模以上のシステム開発では，設計に時間がかかってテストに時間をかけられないこともある．
よって，致命的な障害が発生する可能性がある．
とはいえ，すべてのケースを想定してテストを実施するなどということは現実的ではないので，テストケースを絞る必要がある．
各テストフェーズの礎となる 単体テストが重要 となる

後でまとめてテスト，はダメ

とにかく時間がかかる
問題箇所を切り分けることが難しくなる
モチベーションが下がる
リスクの先送りになりかねない

プロジェクト終盤で行うテストは，再現→原因調査→修正→再テストと，余計に時間がかかるので，プロジェクト序盤から単体テストを実施するべき．

テストの実際

準備するもの

テスト用メインプログラム
- 提供する機能を使う
- うまく機能するかを，プログラム，または人が判断する
関連するモジュール
- （理想的には）テスト済みの下位モジュール
- あるいはその代わりとなる代替インタフェースモジュール

テストできること

提供機能の不具合
インタフェースの自然さ

（参考）ホワイトボックス法とブラックボックス法

動作チェックのために必要な値を含めたデータのことを「テストデータ」と呼びます．このテストデータを，実際にプログラムをコーディングする「エンジニア側の視点」から作ることを「ホワイトボックス法」，モジュールやシステムを使う「ユーザ側の視点」から作ることを「ブラックボックス法」と呼びます．

ホワイトボックス法

プログラムの処理手順や処理内容といった内部構造を意識して，バグが発見できるようにテストデータを作り込みます．ソースプログラム中の文，分岐，条件などを網羅的に実行してバグを見つけます．

テスト	内容
ステートメントカバレッジ（命令網羅）	ソースコードの全命令・文のうち，１回でも実行されたステートメントの割合
ブランチカバレッジ（分岐網羅）	ソースコードの全分岐のうち，１回でも実行された分岐の割合
コンディションカバレッジ（条件網羅）	ソースコードの分岐に設定されている１つ１つの条件が成立・不成立の両方が実行された割合

ブラックボックス法

プログラムの内部構造をあまり意識せず，「このデータを処理したら，結果としてAという値が返ってこなければならない」といった要件をクリアできるかどうか，を検証するようなテストデータを作るやり方をいいます．モジュールを統合した以降のテストに使われる技法です．

テスト	内容
同値分割法	プログラムが期待する「有効同値」及び「無効同値」を入力として結果を確認
境界値分割法	プログラムの「有効同値」と「無効同値」の境界となる値を入力して結果を確認