テスト駆動開発のはじめ方2013.03.2 CLR/H

Shuji Watanabe (@shuji_w6e)

113年3月2日土曜日

自己紹介13年3月2日土曜日

渡辺 修司 / @shuji_w6e札幌Javaコミュニティ

やさしいデスマーチ（Blog）

Java, Groovy, JavaScript, Ruby, TDD

JUnit実践入門

https://forkwell.com/u/shuji.w6e

ロードバイク, フットサル, スノーボード

13年3月2日土曜日

テスト駆動開発とは?13年3月2日土曜日

リファクタリング

テストファースト

13年3月2日土曜日

テスト駆動開発とは、プロダクションコードよりも先にテストコードを書くテストファーストを基盤とした反復的な開発手法。先にテストを意識することにより設計を駆動し、常にリファクタリングを行うことで動作するきれいなコードを手に入れることができる。

13年3月2日土曜日

テスト駆動開発のサイクル1.設計する

2.テストを書く

3.コードを書く

4.テストを成功させる

5.リファクタリング

Heuristics

13年3月2日土曜日

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

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

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

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

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

13年3月2日土曜日

問. どのくらい事前設計すべきでしょうか？どうすれば、いつやめるかわかるのでしょうか？

テスト駆動開発のFAQ

答. 何を構築すべきかわかるまでです。Derick Bailey

http://www.infoq.com/jp/news/2008/03/tdd-smells

13年3月2日土曜日

何を構築すべきか？

13年3月2日土曜日

顧客が本当に必要だったものシステム開発の目的は顧客の要件の実現

13年3月2日土曜日

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

外部的振る舞いを設計する

システムが満たすべきテストケース

13年3月2日土曜日

外部設計とテストリスト

顧客の要件

プログラム

外部設計

テストリスト「何を構築するか？」

13年3月2日土曜日

外部設計とテストリスト

顧客の要件

プログラム

外部設計

テストリスト「何を構築するか？」

13年3月2日土曜日

テストリストとTDD

顧客の要件

プログラム

テストリスト「何を構築するか？」

TDD

13年3月2日土曜日

テストリストとTDD

顧客の要件

プログラム

テストリスト「何を構築するか？」

TDD

13年3月2日土曜日

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

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

要件を満たすテストリストを作ることが重要

13年3月2日土曜日

外部設計の手法顧客のことばを使う

ユースケース

ユーザーストーリー

顧客が理解できるツールを使う

画面や帳票のモックアップ

13年3月2日土曜日

開発プロセスと外部設計

13年3月2日土曜日

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

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

外部設計

プログラミング

テスト

13年3月2日土曜日

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

利用者視点

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

システム化するスコープ

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

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

13年3月2日土曜日

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

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

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

外部インターフェイス

ユーザ

システム境界

システム

外部システム機能 データ

13年3月2日土曜日

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

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

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

要件定義 外部設計 実装

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

13年3月2日土曜日

ユースケース駆動開発を活用したテスト駆動開発

13年3月2日土曜日

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

アクター

システム

ユースケース

ユースケース

System Software

Heuristics

トレーサビリティ

13年3月2日土曜日

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

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

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

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

ユースケース

13年3月2日土曜日

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

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

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

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

13年3月2日土曜日

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

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

重複を整理

関連するものをまとめる

本質はユースケース

13年3月2日土曜日

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

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

実装に依存しない形

要求分析に適する

実装に結びつけにくい実装

要求

本質ユースケースシステムユースケース

抽象的

具体的

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

13年3月2日土曜日

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

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

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

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

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

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

13年3月2日土曜日

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

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

バウンダリ

コントローラ

エンティティ

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

バウンダリ コントローラ

エンティティ

アクター

13年3月2日土曜日

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

クラスの候補

メソッドの候補

何を構築すべきか？

13年3月2日土曜日

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

Rails, JavaEE, Django, CakePHP

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

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

13年3月2日土曜日

ユースケースシナリオを例にするユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す2.システムは、対象のドリンクを排出する3.ユーザは、払い出しボタンを押す4.システムは、お釣りを払い出す

具体的な例とすることで

テストできる

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

13年3月2日土曜日

ユースケースシナリオを例にするユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す2.システムは、対象のドリンクを排出する3.ユーザは、払い出しボタンを押す4.システムは、お釣りを払い出す

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

具体的な例とすることで

テストできる

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

13年3月2日土曜日

ユースケースシナリオを例にするユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す2.システムは、対象のドリンクを排出する3.ユーザは、払い出しボタンを押す4.システムは、お釣りを払い出す

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

具体的な例とすることで

テストできる

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

受け入れテスト（Cucumberなど）

13年3月2日土曜日

ユースケースシナリオを例にするユーザは、お金を投入する 1.ユーザは、購入するドリンクのボタンを押す2.システムは、対象のドリンクを排出する3.ユーザは、払い出しボタンを押す4.システムは、お釣りを払い出す

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

具体的な例とすることで

テストできる

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

受け入れテスト（Cucumberなど）

# language: jaフィーチャ: 自動販売機で飲み物を購入 シナリオ: コーラを1本買う 前提 '100'円を'2'枚投入する もし 'コーラ'のボタンを押した ならば 'コーラ'が出力される かつ お釣りは'10'円が’8’枚である

13年3月2日土曜日

各ステップをテストリストにする1.ユーザは、お金を投入する2.ユーザは、購入するドリンクのボタンを押す3.システムは、対象のドリンクを排出する4.ユーザは、払い出しボタンを押す5.システムは、お釣りを払い出す

13年3月2日土曜日

各ステップをテストリストにする1.ユーザは、お金を投入する2.ユーザは、購入するドリンクのボタンを押す3.システムは、対象のドリンクを排出する4.ユーザは、払い出しボタンを押す5.システムは、お釣りを払い出す

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

13年3月2日土曜日

各ステップをテストリストにする1.ユーザは、お金を投入する2.ユーザは、購入するドリンクのボタンを押す3.システムは、対象のドリンクを排出する4.ユーザは、払い出しボタンを押す5.システムは、お釣りを払い出す

•（初期状態で）合計金額は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));}

13年3月2日土曜日

ユースケース駆動開発とTDDユースケース

TDDクラス/メソッド クラス/メソッド

クラス/メソッド クラス/メソッド

TDDクラス/メソッド クラス/メソッド

クラス/メソッド クラス/メソッド

ユースケースユースケース

受入テスト（機能テスト）

受入テスト（機能テスト）

13年3月2日土曜日

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

自動化できればベスト

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

システムの完成度

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

現実として進捗管理が必要

13年3月2日土曜日

まとめTDDだけでは良いシステムは作れない

顧客の要件からテストリストを導く

ユースケースシナリオとテストリスト

テストリストから実装を導く（TDD）

13年3月2日土曜日

おすすめの書籍ユースケース駆動開発実践ガイド

実践アジャイルテスト

JUnit実践入門

13年3月2日土曜日