ユースケースからテスト駆動開発へ
- 4. ユースケースから テスト駆動開発へ 2.0 2013.01.13 TDD BootCamp 大阪 Shuji Watanabe (@shuji_w6e) 3 13年1月14日月曜日
- 5. テスト駆動開発のFAQ 問. どのくらい事前設計すべきでしょうか？ どうすれば、いつやめるかわかるのでしょうか？ 答. 何を構築すべきかわかるまでです。 Derick Bailey http://www.infoq.com/jp/news/2008/03/tdd-smells 13年1月14日月曜日
- 6. TDDが解決すること・ しないこと 13年1月14日月曜日
- 7. TDDは開発手法 良いプログラムは開発できるが、良いシステ ムを開発できるわけではない 良いシステム ＝ 顧客の要件を満たすシステム なんらかの開発プロセスは必要 アジャイルでもウォーターフォールでも 13年1月14日月曜日
- 8. TDDはテストリストが起点 プログラムが満たすべき仕様をリスト化 最初に全てを抽出できない テストリストは随時、追加・修正 ただし、具体的な仕様（例）が必要 例：getListで1件のデータが取得できる 「何を構築すべきか」＝事前設計 13年1月14日月曜日
- 9. プログラムの仕様と要件 システム開発の目的は顧客の要件の実現 仕様が要件を満たしていなければ本末転倒 要件から「何を構築するか」を設計する 13年1月14日月曜日
- 10. TDDが解決する範囲 TDD 顧客の要件 テストリスト 「何を構築するか？」 プログラム 13年1月14日月曜日
- 11. 「何を構築するか？」を決める 顧客の言葉を使ったシステムの使い方 ユースケース ユーザーストーリー システムの外部的な振る舞い 画面モックアップ APIや他システム連携 13年1月14日月曜日
- 13. 開発プロセス ソフトウェアを作るための手順・段階 アジャイルでもWFでも基本は変わらない 要件定義 外部設計 プログラミング テスト 13年1月14日月曜日
- 14. 外部設計 システムの外部的振る舞い 利用者視点 要件定義とのトレーサビリティ システム化するスコープ 実装とのトレーサビリティ 内部（システム化方式）に依存しない 13年1月14日月曜日
- 15. システム境界 システムと外部との接点 どこからがシステムの機能・データなのか？ ユーザーインターフェイス（画面） 外部インターフェイス システム境界 システム 機能 データ ユーザ 外部システム 13年1月14日月曜日
- 16. トレーサビリティ 追跡（トレース）性 成果物同士が論理的に繋がっているか？ 各フェイズでの成果物の整合性も必須 要件定義 外部設計 実装 比較的に保てる 保ちにくい 13年1月14日月曜日
- 17. ユースケース駆動開発 ユースケース駆動開発とは、ユースケースを開 発の基点として顧客の要件を定義し、ユースケ ースから設計・実装までのトレーサビリティを 保つ事を重視して開発を進める開発手法。 システム トレーサビリティ ユースケース System Software ユースケース アクター Heuristics 13年1月14日月曜日
- 18. ユースケース システムの機能を表すシナリオ（使用例） 外部的な振る舞いと内部的な振る舞い システムと外部とのやり取りを記述する 要件定義フェイズで抽出され、 外部設計フェイズで詳細化する 13年1月14日月曜日
- 19. 自動販売機でドリンクを購入する ユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す 2.システムは、対象のドリンクを排出する 3.ユーザは、払い出しボタンを押す 4.システムは、お釣りを払い出す システムとユーザのインタラクションを記述 1行で1つのアクションを記述 文末は「∼する」（「∼できる」は厳禁） 13年1月14日月曜日
- 20. 参考)ユースケース図 ユースケースとアクターとの関係 構造化されたインデックス 重複を整理 関連するものをまとめる 本質はユースケース 13年1月14日月曜日
- 21. 参考) 本質ユースケース ビジネスユースケース/ 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年1月14日月曜日
- 22. ユースケースから テスト駆動開発へ 13年1月14日月曜日
- 23. ユースケースから実装を導く ユースケースから実装を導く ユースケースが適切である事が前提 つまり、顧客の言葉である ユースケースからオブジェクト(名詞)を抽出 「表示する」「取得する」など動詞 アーキテクチャに依存しない 13年1月14日月曜日
- 24. ロバストネス分析 ユースケースからオブジェクトを抽出・整理 するための分析方法 ユースケースを３つの要素に分解する バウンダリ アクター バウンダリ コントローラ コントローラ エンティティ エンティティ ユースケースに対する健全性チェック 13年1月14日月曜日
- 25. 自動販売機でドリンクを購入する 1.ユーザは、お金を投入する 2.ユーザは、購入するドリンクのボタンを押す 3.システムは、対象のドリンクを排出する 4.ユーザは、払い出しボタンを押す メソッドの候補 クラスの候補 何を構築すべきか？ 13年1月14日月曜日
- 26. アーキテクチャの適用 言語/フレームワークの選択 Rails, JavaEE, Django, CakePHP 細かい点は異なるが骨格は変わらない ユースケース ＋ アーキテクチャ 実装可能 13年1月14日月曜日
- 27. ユースケースシナリオを例にする ユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す 2.システムは、対象のドリンクを排出する 3.ユーザは、払い出しボタンを押す 4.システムは、お釣りを払い出す 具体的な例とすることで テストできる 問題点に気付くことができる 13年1月14日月曜日
- 28. ユースケースシナリオを例にする 1.ユーザは、100硬貨を2枚を投入する ユーザは、お金を投入する 2.ユーザは、コーラのボタンを押す 1.ユーザは、購入するドリンクのボタンを押す 3.システムは、コーラを排出する 2.システムは、対象のドリンクを排出する 4.ユーザは、払い出しボタンを押す 3.ユーザは、払い出しボタンを押す 5.システムは、10硬貨を8枚を払い出す 4.システムは、お釣りを払い出す 具体的な例とすることで テストできる 問題点に気付くことができる 13年1月14日月曜日
- 29. ユースケースシナリオを例にする 1.ユーザは、100硬貨を2枚を投入する ユーザは、お金を投入する 2.ユーザは、コーラのボタンを押す 受け入れテスト 1.ユーザは、購入するドリンクのボタンを押す 3.システムは、コーラを排出する 2.システムは、対象のドリンクを排出する （Cucumberなど） 4.ユーザは、払い出しボタンを押す 3.ユーザは、払い出しボタンを押す 5.システムは、10硬貨を8枚を払い出す 4.システムは、お釣りを払い出す 具体的な例とすることで テストできる 問題点に気付くことができる 13年1月14日月曜日
- 30. ユースケースシナリオを例にする 1.ユーザは、100硬貨を2枚を投入する ユーザは、お金を投入する 2.ユーザは、コーラのボタンを押す 受け入れテスト 1.ユーザは、購入するドリンクのボタンを押す 3.システムは、コーラを排出する 2.システムは、対象のドリンクを排出する （Cucumberなど） 4.ユーザは、払い出しボタンを押す 3.ユーザは、払い出しボタンを押す 5.システムは、10硬貨を8枚を払い出す 4.システムは、お釣りを払い出す # language: ja フィーチャ: 自動販売機で飲み物を購入 具体的な例とすることで シナリオ: コーラを1本買う 前提 '100'円を'2'枚投入する テストできる もし 'コーラ'のボタンを押した ならば 'コーラ'が出力される かつ お釣りは'10'円が’8’枚である 問題点に気付くことができる 13年1月14日月曜日
- 31. 各ステップをテストリストにする 1.ユーザは、お金を投入する 2.ユーザは、購入するドリンクのボタンを押す 3.システムは、対象のドリンクを排出する 4.ユーザは、払い出しボタンを押す 5.システムは、お釣りを払い出す 13年1月14日月曜日
- 32. 各ステップをテストリストにする 1.ユーザは、お金を投入する 2.ユーザは、購入するドリンクのボタンを押す • （初期状態で）合計金額は0円である 3.システムは、対象のドリンクを排出する • 100円硬貨を投入すると、合計金額が100円である 4.ユーザは、払い出しボタンを押す • 100円硬貨を投入されている時に、 5.システムは、お釣りを払い出す 10円硬貨を投入すると、合計金額が110円である 13年1月14日月曜日
- 33. 各ステップをテストリストにする 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年1月14日月曜日
- 34. ユースケース駆動開発とTDD ユースケース TDD クラス/メソッド クラス/メソッド 受入テスト クラス/メソッド クラス/メソッド （機能テスト） TDD クラス/メソッド クラス/メソッド クラス/メソッド クラス/メソッド 受入テスト ユースケース （機能テスト） ユースケース 13年1月14日月曜日
- 35. ユースケース駆動開発の利点 受入テストが設計時に明確 自動化できればベスト 適切な粒度の「何を構築すべきか？」 システムの完成度 本来はユースケース単位で意味がある 現実として進 管理が必要 13年1月14日月曜日
- 36. まとめ ユースケースでシステム全体を設計する 顧客視点でシステム境界を明確にする ユースケースは受入テスト ユースケースから実装が導ける事が重要 ユースケースの１文は「構築すべきこと」 テスト駆動開発の起点 テストリスト 13年1月14日月曜日