のみほーだい!

アジャイル・プロセス（Ａｇｉｌｅ　Ｐｒｏｃｅｓｓ）の導入について

第３回　テストファーストの考え方

■テストファーストとは？

XPの説明でも紹介しましたが、コーディングを始める前にそのプログラムをテストするプログラムを作成することを指します。従来の方法では、要件定義→設計→コーディング→テスト環境整備→テスト実施の順で作業しましたが、テストファーストではコーディングとテスト環境整備の順番が逆になっています。
　XPの各手法の中でも特に斬新的な項目と見られがちですが、コーディング前にテスト仕様書を作成する方が効果的に開発できることは以前から知られていました。XP・RUPなどの反復的開発手法では当然テストも繰り返して行なわれるので、テストを自動的に行なえるように更にテスティングフレームワークというものが導入されました。

コーディングより先にテストの準備をする利点は、

●入力条件や処理結果が具体的な値で記述される 　→ 　仕様の誤った解釈を防止 ●例外条件、異常処理なども詳細に検討される 　→ 　要件定義の抜けの早期発見 ●細かい単位でテストできる 　→ 　範囲が限定されバグの特定が容易 ●テスト環境が財産として残る 　→ 　デグレード防止 ●誰でも同じテストを実施できる 　→ 　品質のバラツキ防止

という点にあります。

特に強調したいのは、

詳細設計書レベルであれ、プログラムの仕様はどうしても抽象的になりがちで、特にユーザーにとっては、自分の言いたいことが正確に伝わっていたのか判断するのが難しいのです。テスト仕様書では実際の動作がイメージできるので、即座にユーザーが訂正を入れてくるので手戻りが少なくなります。
　また、期待はずれの動作をして「裏切られ感」を与える危険性も減ります。

注意点

いい事尽くめのテストファーストですが、注意すべき点を把握しておかないと大怪我をします。特に今までテスト工程をごまかしていた人にとっては見かけ上の工数が増大するので、文句を言わないように！

　１．個々のプログラムの開発線表にテスト準備工数を組み込むのを忘れないこと。

テスティングフレームワークというのは一度テスト用プログラムを書いてしまえば実行は数秒～数分で済んでしまい非常に効率的なのですが、そのプログラムを準備する工数が結構バカにならないのです。

テスト仕様書のユーザーレビューなどを考慮すると、コーディング工数の１．５～２倍かかると覚悟しましょう。

デザインパターン等を有効利用し、コーディングの生産性を向上させて浮いた分をテスト準備工数に割り振ります。

従来はテストなんかどうでも良いからとにかくモノだけ作ってしまうような蛮行も横行していて、ツケを納品後に回してトラブル対応に追われていましたが、今度はそのようなインチキが通用しません。XPで説明したスコープを上手く制御して、必要なプログラムから確実に片付けていくことが重要です。

早期かつ頻繁に価値のあるソフトウェアを納品することによりユーザーを満足させることを最優先とします。

　２．テスト用プログラムのバグに注意すること。

テスト用であれプログラムである以上、当然バグを含んでいることを想定すべし。特に処理結果の判断ミスにより、誤動作を正常と判断して見過ごしていないか常に留意しなくてはなりません。事情が許せば複数人によるソースレビューを行ないます。

■ＪＵｎｉｔ

特徴

　・自動化

JUnitはテストを自動実行するだけでなく、テスト結果も自動的にチェックする。

結果はビジュアル的に分かり易く、エラー時は間違った箇所を指摘してくれる。

　・容易なテストの記述

テスト用のクラスライブラリが充実しているのでテスト用コードを手早く書ける。

　・テストケースの階層化

複数のテストケースをグループ化することができ、更にそのグループもグループ化できるために全体をツリー型に構成して全体を分かり易く整理することができる。

構造

インストール

　・入手先
　　JUnitのＷｅｂサイト（http://www.junit.org/）から最新のzipファイル（2005.2現在：junit3.8.1.zip）をダウンロードします。
　・設定
　　ダウンロードしたzipファイルを任意のフォルダに展開後、環境変数（クラスパス）にそのパスを追加します。
　　以下の説明では「C:\junit3.8」に展開したものとしています。
　　Windows95/98の場合
　　　　autoexec.batをエディタで編集し「classpath C:\junit3.8\junit.jar」を追加します。
　　WindowsNTの場合
　　　　「システムのプロパティ」ダイアログボックスの「環境」タブを選択する。
　　　　「変数：」欄に環境変数として「classpath」を入力し、「値：」欄に「C:\junit3.8\junit.jar」を入力します。
　　　　既にclasspath変数が登録されている場合は、パスを追加します。
　　Windows2000の場合
　　　　「システムのプロパティ」ダイアログボックスの「詳細」タブを選択します。
　　　　「環境変数：」ボタンをクリックしユーザー環境変数欄に「classpath」を登録します。
　　　　（登録内容はWindowsNTの場合と同じ）
　　尚、一時的に環境変数へパスを設定する場合はsetコマンドを使用します。

動作確認

　JUnitに付属するサンプルプログラムをTestRunnerで動作させセットアップが正しく完了したか確認します。
　CUI版TestRunnerでの確認
　　prompt>java junit.textui.TestRunner junit.samples.AllTests
　AWT版TestRunnerでの確認
　　prompt>java junit.awtui.TestRunner junit.samples.AllTests
　Swing版TestRunnerでの確認
　　prompt>java junit.swingui.TestRunner junit.samples.AllTests

ファイル構成

テストプログラム作成手順

　説明のために簡単なサンプルクラスを作成します。

　　クラス名：SampleForJunitTest

　　コンストラクタ：SampleForJunitTest (int iVal);

引数で渡された値を保持します。

引数のチェックは行いません。

　　メソッド：int getValue()

現在保持している値を返します。

　　メソッド：int doAddition(int iVal) throws IllegalArgumentException

現在保持している値に引数で渡された値を加算した結果を返します。
結果はprivateなフィールドとして保持します。
引数として負の値が渡されたときはIllegalArgumentExceptionを投げます。

　　publicフィールド：なし

　　テストケース１：コンストラクタのテスト

確認事項：引数で渡された値がprivateなフィールドとして保持されていること

　　テストケース２：アクセサのテスト

確認事項：getterメソッドがフィールドに保持されている値を正しく返すこと

　　テストケース３：演算処理テスト

確認事項：演算結果が正しく返されること

　　テストケース４：例外テスト

確認事項：引数に負の値を渡した時に例外が発生すること

①　テスト対象クラスのスケルトン作成

package jp.co.itd.junit_sample;

public class SampleForJunitTest {

    private int _iValue;    // 計算結果を保持するprivateフィールド

    public  SampleForJunitTest(int iVal) {
    }

    public  int getValue() {
    }

    public  int doAddition(int iVal) {
    }
}

　テストファーストと言ってもインタフェース部分は作成しておかないとテストプログラムのコンパイルも通らないのでクラス図に基づき最低限の定義はしておきます。

②　テストコード記述

　　テストケース１用

import  junit.framework.*;
import  jp.co.itd.junit_sample.*;
public class TestConstructor extends TestCase
{
    private SampleForJunitTest obj;

    // コンストラクタ
    public TestConstructor(String name) { Super(name); }

    // 初期設定
    protected void setUp() { obj = new SampleForJunitTest(10); }

    // テスト実行
    public void runTest() {
        testSampleConstructor();
}

// 終了処理
public void tearDown() { }

    // コンストラクタのテスト
    public void testSampleConstructor()
    {
        Class objClass = obj.getClass();                       // Class ｵﾌﾞｼﾞｪｸﾄ取得
        Field objField = objClass.getDeclaredField("_iValue ");  // Field ｵﾌﾞｼﾞｪｸﾄ取得
        objField.setAccessible(true);                          // フィールドをアクセス可能に
    assertEquals("_iValue", objField.getInt(obj),10);        // 仕様通りなら_iValueが10の筈
    }
}

　　テストケース２用

import  junit.framework.*;
import  jp.co.itd.junit_sample.*;
public class TestAccessor extends TestCase
{
    private SampleForJunitTest obj;

    public TestAccessor (String name) { Super(name); }
    protected void setUp() { obj = new SampleForJunitTest(20); }
    public void runTest() {
testGetValue();
    }
    public void tearDown() {}

    // getterメソッドのテスト
    public void testGetValue()
    {
        assertEquals("getValue", obj.getValue(),20);
    }
}

　　テストケース３用

import  junit.framework.*;
import  jp.co.itd.junit_sample.*;
public class TestOperator extends TestCase
{
    private SampleForJunitTest obj;

    public TestOperator (String name) { Super(name); }
    protected void setUp() { obj = new SampleForJunitTest(50); }
    public void runTest() {
        testDoAddition();
        testSaveValue();
    }
    public void tearDown() {}

    // 演算処理のテスト
    public void testDoAddition()
    {
        assertEquals("doAddition", obj. doAddition (40),70);
    }
// データ保持の確認
public void testSaveValue()
{
        assertEquals("saved value", obj.getValue(),70);
    }
}

　　テストケース４用

import  junit.framework.*;
import  jp.co.itd.junit_sample.*;
public class TestException extends TestCase
{
    private SampleForJunitTest obj;

    public TestException (String name) { Super(name); }
    protected void setUp() { obj = new SampleForJunitTest(60); }
    public void runTest() throws Exception
    {
        testSampleException();
    }
    public void tearDown() {}

    // 例外処理のテスト
    public void testSampleException()
    {
        try {
            obj. doAddition (-80);    // わざと例外発生
            fail("IllegalArgumentException発生していない");
        } catch (IllegalArgumentException ie) {
        } catch (Exception e) {
            fail("別の例外が発生してしまった");
        }
    }

}

③　テストケースのグループ化

テストケース１～４を一度にテストできる様にまとめます。

import  junit.framework.*;
import  jp.co.itd.junit_sample.*;
public class TestJunitSample extends TestSuite
{
    public TestJunitSample (String name) { Super(name); }
    public static TestSuite suite() {
        TestSuite testSuite = new TestJunitSample ("JUnit Test Sample");
        testSuite.addTest(new TestConstructor ("Constructor test"));
        testSuite.addTest(new TestAccessor ("Accessor test"));
        testSuite.addTest(new TestOperator ("Operator test"));
        testSuite.addTest(new TestException ("Exception test"));
        return testSuite;
    }
}

④　テスト実行

　今作成したテスト用プログラムをコンパイルして実行してみます。
　メソッド内部は何も実装されていないので当然全てエラーとなる筈です。
　この最初にエラーになるのを確認するのがテストファーストの流儀。

⑤　メソッドの実装とテストの繰り返し

　手順４で報告されたエラーに対し、１件ずつ機能を実装させて解消します。最終的にエラーが報告されなくなればコーディング完了です。
　この時、まとめてコーディングを済ませてからテストを実行するのではなく、１つ実装してはテストを実行するという具合にできるだけ短い間隔でテストを繰り返すのがコツ。
　今まで正常に終了していたテストケースが急にエラーになったら、前回テスト実行後変更したところに原因があります。テスト間隔が短いほど範囲が限定されバグの特定が容易になります。
　このように常にデグレードを監視していれば、品質は格段に向上します。