<< 実践 ICONIXプロセス : NGこそ正解 | main | 気分はF1でクラッシュ >>

実践 ICONIXプロセス : 単体テスト

テスト駆動開発(TDD)では、コードを書く前にテストコードを書きます。
ICONIXプロセスでは、コードを自動生成しますので、コードを書いてからテストコードを書きます。

ですから、全く別のアプローチ...

というのは真っ赤なウソです。表面的には正反対に見えます。本質は、テストすべきことを明確にしてから、コードを書く点で同じアプローチです。

テスト駆動開発(TDD)では、テストすべきことをテストケースとして「設計」します。では、その設計の情報源はなんでしょうか?
なんらかの分析モデル、設計モデルを使うことになるのでしょう。まちがった XP 流儀だと参考になるモデルがない状態で、テストケースをひねり出す魔法が必要になります。思いつたことからコーディング?
テストケースを作るために、ヒアリングやモデリングをするというのは、一つの方法論だと思います。でも、結局、テストコードを書く前にモデリングをすることになります。

ICONIXプロセスでは、単体テストのテストケースは、ロバストネス分析の結果をそのまま利用します。ロバストネス図のコントロールが、そのままテストケースです。
テストケースの設計は、予備設計として、詳細設計より前に終わっている作業です。

単体テストのため、いつ、何をやるかは単純明快かつ実践的です。

・テストケースの洗い出しは、ロバスト分析時に終了(コントロールとして定義)
・詳細設計後の詳細クラス図からコード(の雛形)を自動生成
・テストケースごとにテストコードを書く
・テストを実行して失敗(まだコードの雛形だから)
・コードを実装
・テストを実行して成功

ようするに、テストコードを書くためのテストケースは、ロバストネス図で描いたコントロールとして設計済み、ということです。エディタの前で、テストケースに頭をひねるより実践的でしょ?

ロバストネス図とテストコードを比べれば、ロバストネス図は絵ですからテストケースの構成や順番がとてもわかりやすい。
単体テストが不足していないか、単体テストをやりすぎていないか、などの単純にロバストネス図のコントロールとテストケースを付き合わせればチェックできる。この作業をもっと楽にやるために、ロバストネス図から、テストケース図を自動作成するアドインツールもあります。( Enterprise Architectのアドイン)

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM