Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a テスト駆動開発のはじめ方 (20)
Más de Shuji Watanabe (20)
テスト駆動開発のはじめ方
- 1. テスト駆動開発の
はじめ方
2013.03.2 CLR/H
Shuji Watanabe (@shuji_w6e)
1
13年3月2日土曜日
- 3. 渡辺 修司 / @shuji_w6e
札幌Javaコミュニティ
やさしいデスマーチ(Blog)
Java, Groovy, JavaScript, Ruby, TDD
JUnit実践入門
https://forkwell.com/u/shuji.w6e
ロードバイク, フットサル, スノーボード
13年3月2日土曜日
- 7. テスト駆動開発のサイクル
1.設計する
5.リファクタリング
Heuristics
2.テストを書く
4.テストを成功させる
3.コードを書く
13年3月2日土曜日
- 8. TDDはテストリストが起点
プログラムが満たすべき仕様をリスト化
最初に全てを抽出できない
テストリストは随時、追加・修正
ただし、具体的な仕様(例)が必要
例:getListで1件のデータが取得できる
13年3月2日土曜日
- 9. テスト駆動開発のFAQ
問. どのくらい事前設計すべきでしょうか?
どうすれば、いつやめるかわかるのでしょうか?
答. 何を構築すべきかわかるまでです。
Derick Bailey
http://www.infoq.com/jp/news/2008/03/tdd-smells
13年3月2日土曜日
- 12. 何を構築すべきか?
要件から「何を構築するか」を設計する
外部的振る舞いを設計する
システムが満たすべきテストケース
13年3月2日土曜日
- 13. 外部設計とテストリスト
外部設計
顧客の要件
テストリスト
「何を構築するか?」 プログラム
13年3月2日土曜日
- 14. 外部設計とテストリスト
外部設計
顧客の要件
テストリスト
「何を構築するか?」 プログラム
13年3月2日土曜日
- 15. テストリストとTDD
TDD
顧客の要件
テストリスト
「何を構築するか?」 プログラム
13年3月2日土曜日
- 16. テストリストとTDD
TDD
顧客の要件
テストリスト
「何を構築するか?」 プログラム
13年3月2日土曜日
- 17. TDDは開発手法
良いプログラムは開発できるが、良いシステ
ムを開発できるわけではない
良いシステム = 顧客の要件を満たすシステム
要件を満たすテストリストを作ることが重要
13年3月2日土曜日
- 18. 外部設計の手法
顧客のことばを使う
ユースケース
ユーザーストーリー
顧客が理解できるツールを使う
画面や帳票のモックアップ
13年3月2日土曜日
- 20. 開発プロセス
ソフトウェアを作るための手順・段階
アジャイルでもWFでも基本は変わらない
要件定義
外部設計
プログラミング
テスト
13年3月2日土曜日
- 21. 外部設計
システムの外部的振る舞い
利用者視点
要件定義とのトレーサビリティ
システム化するスコープ
実装とのトレーサビリティ
内部(システム化方式)に依存しない
13年3月2日土曜日
- 22. システム境界
システムと外部との接点
どこからがシステムの機能・データなのか?
ユーザーインターフェイス(画面)
外部インターフェイス
システム境界
システム
機能 データ
ユーザ 外部システム
13年3月2日土曜日
- 23. トレーサビリティ
追跡(トレース)性
成果物同士が論理的に繋がっているか?
各フェイズでの成果物の整合性も必須
要件定義 外部設計 実装
比較的に保てる 保ちにくい
13年3月2日土曜日
- 25. ユースケース駆動開発
ユースケース駆動開発とは、ユースケースを開
発の基点として顧客の要件を定義し、ユースケ
ースから設計・実装までのトレーサビリティを
保つ事を重視して開発を進める開発手法。
システム トレーサビリティ
ユースケース System Software
ユースケース
アクター
Heuristics
13年3月2日土曜日
- 26. ユースケース
システムの機能を表すシナリオ(使用例)
外部的な振る舞いと内部的な振る舞い
システムと外部とのやり取りを記述する
要件定義フェイズで抽出され、
外部設計フェイズで詳細化する
13年3月2日土曜日
- 27. 自動販売機でドリンクを購入する
1.ユーザは、お金を投入する
2.ユーザは、購入するドリンクのボタンを押す
3.システムは、対象のドリンクを排出する
4.ユーザは、払い出しボタンを押す
5.システムは、お釣りを払い出す
システムとユーザのインタラクションを記述
1行で1つのアクションを記述
文末は「∼する」(「∼できる」は厳禁)
13年3月2日土曜日
- 28. 参考)ユースケース図
ユースケースとアクターとの関係
構造化されたインデックス
重複を整理
関連するものをまとめる
本質はユースケース
13年3月2日土曜日
- 29. 参考) 本質ユースケース
ビジネスユースケース/ 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
13年3月2日土曜日
- 30. ユースケースから実装を導く
ユースケースから実装を導く
ユースケースが適切である事が前提
つまり、顧客の言葉である
ユースケースからオブジェクト(名詞)を抽出
「表示する」「取得する」など動詞
アーキテクチャに依存しない
13年3月2日土曜日
- 31. ロバストネス分析
ユースケースからオブジェクトを抽出・整理
するための分析方法
ユースケースを3つの要素に分解する
バウンダリ
アクター バウンダリ コントローラ
コントローラ
エンティティ エンティティ
ユースケースに対する健全性チェック
13年3月2日土曜日
- 32. 自動販売機でドリンクを購入する
1.ユーザは、お金を投入する
2.ユーザは、購入するドリンクのボタンを押す
3.システムは、対象のドリンクを排出する
4.ユーザは、払い出しボタンを押す
メソッドの候補
クラスの候補
何を構築すべきか?
13年3月2日土曜日
- 33. アーキテクチャの適用
言語/フレームワークの選択
Rails, JavaEE, Django, CakePHP
細かい点は異なるが骨格は変わらない
ユースケース + アーキテクチャ 実装可能
13年3月2日土曜日
- 34. ユースケースシナリオを例にする
ユーザは、お金を投入する
1.ユーザは、購入するドリンクのボタンを押す
2.システムは、対象のドリンクを排出する
3.ユーザは、払い出しボタンを押す
4.システムは、お釣りを払い出す
具体的な例とすることで
テストできる
問題点に気付くことができる
13年3月2日土曜日
- 35. ユースケースシナリオを例にする
1.ユーザは、100硬貨を2枚を投入する
ユーザは、お金を投入する
2.ユーザは、コーラのボタンを押す
1.ユーザは、購入するドリンクのボタンを押す
3.システムは、コーラを排出する
2.システムは、対象のドリンクを排出する
4.ユーザは、払い出しボタンを押す
3.ユーザは、払い出しボタンを押す
5.システムは、10硬貨を8枚を払い出す
4.システムは、お釣りを払い出す
具体的な例とすることで
テストできる
問題点に気付くことができる
13年3月2日土曜日
- 36. ユースケースシナリオを例にする
1.ユーザは、100硬貨を2枚を投入する
ユーザは、お金を投入する
2.ユーザは、コーラのボタンを押す 受け入れテスト
1.ユーザは、購入するドリンクのボタンを押す
3.システムは、コーラを排出する
2.システムは、対象のドリンクを排出する
(Cucumberなど)
4.ユーザは、払い出しボタンを押す
3.ユーザは、払い出しボタンを押す
5.システムは、10硬貨を8枚を払い出す
4.システムは、お釣りを払い出す
具体的な例とすることで
テストできる
問題点に気付くことができる
13年3月2日土曜日
- 37. ユースケースシナリオを例にする
1.ユーザは、100硬貨を2枚を投入する
ユーザは、お金を投入する
2.ユーザは、コーラのボタンを押す 受け入れテスト
1.ユーザは、購入するドリンクのボタンを押す
3.システムは、コーラを排出する
2.システムは、対象のドリンクを排出する
(Cucumberなど)
4.ユーザは、払い出しボタンを押す
3.ユーザは、払い出しボタンを押す
5.システムは、10硬貨を8枚を払い出す
4.システムは、お釣りを払い出す
# language: ja
フィーチャ: 自動販売機で飲み物を購入
具体的な例とすることで シナリオ: コーラを1本買う
前提 '100'円を'2'枚投入する
テストできる もし 'コーラ'のボタンを押した
ならば 'コーラ'が出力される
かつ お釣りは'10'円が’8’枚である
問題点に気付くことができる
13年3月2日土曜日
- 38. 各ステップをテストリストにする
1.ユーザは、お金を投入する
2.ユーザは、購入するドリンクのボタンを押す
3.システムは、対象のドリンクを排出する
4.ユーザは、払い出しボタンを押す
5.システムは、お釣りを払い出す
13年3月2日土曜日
- 39. 各ステップをテストリストにする
1.ユーザは、お金を投入する
2.ユーザは、購入するドリンクのボタンを押す
• (初期状態で)合計金額は0円である
3.システムは、対象のドリンクを排出する
• 100円硬貨を投入すると、合計金額が100円である
4.ユーザは、払い出しボタンを押す
• 100円硬貨を投入されている時に、
5.システムは、お釣りを払い出す
10円硬貨を投入すると、合計金額が110円である
13年3月2日土曜日
- 40. 各ステップをテストリストにする
1.ユーザは、お金を投入する
2.ユーザは、購入するドリンクのボタンを押す
• (初期状態で)合計金額は0円である
3.システムは、対象のドリンクを排出する
• 100円硬貨を投入すると、合計金額が100円である
4.ユーザは、払い出しボタンを押す
• 100円硬貨を投入されている時に、
5.システムは、お釣りを払い出す
10円硬貨を投入すると、合計金額が110円である {
@Test public void 初期状態でgetTotalAmountは0を返す() throws Exception
VendingMachine sut = new VendingMachine();
int actual = sut.getTotalAmount();
assertThat(actual, is(0));
}
13年3月2日土曜日
- 41. ユースケース駆動開発とTDD
ユースケース
TDD
クラス/メソッド クラス/メソッド
受入テスト クラス/メソッド クラス/メソッド
(機能テスト) TDD
クラス/メソッド クラス/メソッド
クラス/メソッド クラス/メソッド
受入テスト
ユースケース
(機能テスト)
ユースケース
13年3月2日土曜日
- 42. ユースケース駆動開発の利点
受入テストが設計時に明確
自動化できればベスト
適切な粒度の「何を構築すべきか?」
システムの完成度
本来はユースケース単位で意味がある
現実として進 管理が必要
13年3月2日土曜日
- 43. まとめ
TDDだけでは良いシステムは作れない
顧客の要件からテストリストを導く
ユースケースシナリオとテストリスト
テストリストから実装を導く(TDD)
13年3月2日土曜日
- 44. おすすめの書籍
ユースケース駆動開発実践ガイド
実践アジャイルテスト
JUnit実践入門
13年3月2日土曜日