ユースケースからテスト駆動開発へ

札幌からきますた

13年1月14日月曜日

ユースケースから
テスト駆動開発へ 2.0
2013.01.13 TDD BootCamp 大阪
Shuji Watanabe (@shuji_w6e)

3

テスト駆動開発のFAQ
問. どのくらい事前設計すべきでしょうか？
どうすれば、いつやめるかわかるのでしょうか？

答. 何を構築すべきかわかるまでです。
Derick Bailey
http://www.infoq.com/jp/news/2008/03/tdd-smells


TDDが解決すること・
しないこと


TDDは開発手法
良いプログラムは開発できるが、良いシステ
ムを開発できるわけではない

良いシステム＝顧客の要件を満たすシステム

なんらかの開発プロセスは必要

アジャイルでもウォーターフォールでも


TDDはテストリストが起点
プログラムが満たすべき仕様をリスト化

最初に全てを抽出できない

テストリストは随時、追加・修正

ただし、具体的な仕様（例）が必要

例：getListで1件のデータが取得できる

「何を構築すべきか」＝事前設計


プログラムの仕様と要件
システム開発の目的は顧客の要件の実現

仕様が要件を満たしていなければ本末転倒

要件から「何を構築するか」を設計する


TDDが解決する範囲

TDD
顧客の要件
テストリスト
「何を構築するか？」プログラム


「何を構築するか？」を決める
顧客の言葉を使ったシステムの使い方

ユースケース

ユーザーストーリー

システムの外部的な振る舞い

画面モックアップ

APIや他システム連携


ユースケース駆動開発


開発プロセス
ソフトウェアを作るための手順・段階

アジャイルでもWFでも基本は変わらない
要件定義

外部設計

プログラミング

テスト


外部設計
システムの外部的振る舞い

利用者視点

要件定義とのトレーサビリティ

システム化するスコープ

実装とのトレーサビリティ

内部（システム化方式）に依存しない


システム境界
システムと外部との接点

どこからがシステムの機能・データなのか？

ユーザーインターフェイス（画面）

外部インターフェイス
システム境界

システム

機能データ
ユーザ外部システム


トレーサビリティ
追跡（トレース）性

成果物同士が論理的に繋がっているか？

各フェイズでの成果物の整合性も必須

要件定義外部設計実装

比較的に保てる保ちにくい


ユースケース駆動開発
ユースケース駆動開発とは、ユースケースを開
発の基点として顧客の要件を定義し、ユースケ
ースから設計・実装までのトレーサビリティを
保つ事を重視して開発を進める開発手法。

システムトレーサビリティ
ユースケース System Software

ユースケース
アクター
Heuristics


ユースケース
システムの機能を表すシナリオ（使用例）

外部的な振る舞いと内部的な振る舞い

システムと外部とのやり取りを記述する

要件定義フェイズで抽出され、
外部設計フェイズで詳細化する


自動販売機でドリンクを購入する
ユーザは、お金を投入する
1.ユーザは、購入するドリンクのボタンを押す
2.システムは、対象のドリンクを排出する
3.ユーザは、払い出しボタンを押す
4.システムは、お釣りを払い出す

システムとユーザのインタラクションを記述

1行で1つのアクションを記述

文末は「∼する」（「∼できる」は厳禁）


参考)ユースケース図
ユースケースとアクターとの関係

構造化されたインデックス

重複を整理

関連するものをまとめる

本質はユースケース


参考) 本質ユースケース
ビジネスユースケース/ Essential Use Case

簡潔で、抽象化され、一般的なユースケース

実装に依存しない形
要求
抽象的
要求分析に適する本質ユースケース

システムユースケース

実装に結びつけにくい
具体的実装

http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/artifacts/essentialUseCase.html
http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/artifacts/systemUseCase.html


ユースケースから
テスト駆動開発へ


ユースケースから実装を導く
ユースケースから実装を導く

ユースケースが適切である事が前提

つまり、顧客の言葉である

ユースケースからオブジェクト(名詞)を抽出

「表示する」「取得する」など動詞

アーキテクチャに依存しない


ロバストネス分析
ユースケースからオブジェクトを抽出・整理
するための分析方法

ユースケースを３つの要素に分解する

バウンダリ
アクターバウンダリコントローラ

コントローラ

エンティティエンティティ

ユースケースに対する健全性チェック


自動販売機でドリンクを購入する
1.ユーザは、お金を投入する

メソッドの候補

クラスの候補

何を構築すべきか？


アーキテクチャの適用
言語/フレームワークの選択

Rails, JavaEE, Django, CakePHP

細かい点は異なるが骨格は変わらない

ユースケース＋アーキテクチャ実装可能


ユースケースシナリオを例にする

具体的な例とすることで

テストできる

問題点に気付くことができる


1.ユーザは、100硬貨を2枚を投入する
2.ユーザは、コーラのボタンを押す
3.システムは、コーラを排出する
5.システムは、10硬貨を8枚を払い出す


テストできる



2.ユーザは、コーラのボタンを押す受け入れテスト
（Cucumberなど）


テストできる



2.ユーザは、コーラのボタンを押す受け入れテスト
（Cucumberなど）
# language: ja
フィーチャ: 自動販売機で飲み物を購入
具体的な例とすることでシナリオ: コーラを1本買う
前提 '100'円を'2'枚投入する

テストできるもし 'コーラ'のボタンを押した
ならば 'コーラ'が出力される
かつお釣りは'10'円が’8’枚である



各ステップをテストリストにする


• （初期状態で）合計金額は0円である
• 100円硬貨を投入すると、合計金額が100円である
• 100円硬貨を投入されている時に、
10円硬貨を投入すると、合計金額が110円である


• （初期状態で）合計金額は0円である
• 100円硬貨を投入すると、合計金額が100円である
• 100円硬貨を投入されている時に、
10円硬貨を投入すると、合計金額が110円である {
@Test public void 初期状態でgetTotalAmountは0を返す() throws Exception
VendingMachine sut = new VendingMachine();
int actual = sut.getTotalAmount();
assertThat(actual, is(0));
}


ユースケース駆動開発とTDD
ユースケース
TDD
クラス/メソッドクラス/メソッド

受入テストクラス/メソッドクラス/メソッド

（機能テスト） TDD


受入テスト
ユースケース
（機能テスト）
ユースケース

ユースケース駆動開発の利点
受入テストが設計時に明確

自動化できればベスト

適切な粒度の「何を構築すべきか？」

システムの完成度

本来はユースケース単位で意味がある

現実として進管理が必要


まとめ
ユースケースでシステム全体を設計する

顧客視点でシステム境界を明確にする

ユースケースは受入テスト

ユースケースから実装が導ける事が重要

ユースケースの１文は「構築すべきこと」

テスト駆動開発の起点テストリスト


ユースケースからテスト駆動開発へ

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to ユースケースからテスト駆動開発へ

Similar to ユースケースからテスト駆動開発へ (20)

More from Shuji Watanabe

More from Shuji Watanabe (20)

ユースケースからテスト駆動開発へ