TDDの原理～スペック・ファースト

biac (山本康彦)
BluewaterSoft http://www.bluewatersoft.jp/
略歴
- 名古屋大学工学部(修士)
- HONDA R&Dで自動車設計
- 1994～ソフトウェア業界
- 2012～ BluewaterSoft
著書
「速攻入門 C#」(2012/3) 技術評論社、共著
「ソフトな彼女とハードな彼氏。」(2012/3) アジャイルマインドvol.1掲載

2013/1/18 Visual Studio ハッカソン事前勉強会 2

連載
「C#でTDD入門」 CodeZine
「WinRT/Metro Tips」 @IT .NET開発者中心

Web
TDD.NET http://www.tdd-net.jp/
biac のそれさえもおそらくは幸せな日々@nifty
http://bluewatersoft.cocolog-nifty.com/blog/


“Test Driven Development:
By Example” (2002) 参考訳
We drive 自動化されたテストを
development with 使って、私たちは開発
automated tests, a を駆動する。それがテ
style of development スト駆動開発(TDD)と呼
called Test-Driven ばれる開発のスタイル
Development (TDD). だ。

× テスト × テストが駆動する
○ 自動化されたテスト ○ 私たちが駆動する

“Test Driven Development: テストファースト
By Example” (2002) 参考訳
In Test-Driven TDDでは、
Development, we ・自動化されたテスト
・Write new code が失敗したときだけ、
only if an automated 新しいコードを書く
test has failed ・重複を無くす
・Eliminate
duplication たった2つのシンプルな
ルール
These are two simple
rules. リファクタリング


レッド / グリーン / リファクタ
「黄金の三角形」by @t_wada
テストファースト
失敗する自動化されたテスト ⇒
新しいコードを書いてパスさせる ⇒
リファクタリング
All Greenを維持したまま改良 ⇒


プロのモノ作りとして当たり前の手順


私の造語
あまりにも当たり前すぎて、この概念を示
す言葉が無いっぽい
つまり…
なにを作るかを決めてから
↓
どうやって作るかを考える


スペックを決める
- 外観
- 性能 ex)最高速300km/h以上 etc.

↓

作り方を考える
- 構造は?
- 部品は?
- 製造ラインは?
画像は「自動車製品開発のプロセスと組織」(藤本隆宏)より

スペックを決めてから
→ 作り方を考える

ゴールを決めてから
→ それをクリアすべく行動する

外部設計 (external design - 外から見た設計)
→ 内部設計 (internal design - 内から見た設計)
※ 外部設計を満たすような内部構造を設計


An act of identifying something precisely or
of stating a precise requirement.
( Oxford Dictionaries
http://oxforddictionaries.com/definition/english/specification )
何かを正確に識別するか、正確な要求を述
べる行為
Could you be a little more specific？
もう少し具体的に言ってください
スペック＝具体的な要求
製造業の製品開発においては、
検証可能(合否を判断できる)であること。

an abstract idea
( Oxford Dictionaries
http://oxforddictionaries.com/definition/english/concept )
抽象的なアイデア
「世界一速いクルマ」 ← コンセプト、要望
「2ℓエンジン市販車で最高速300km/h超」
← スペック、仕様
違いは、検証可能かどうか。
言い換えると「テスタブル」か否か。
あなたのところの要件定義書や外部設計書
は、スペック? or コンセプト?

スペックファーストしてますか?

製造業で部品の図面を描くとき。
たとえば、ネジ1本
1. 設計者は、ネジのスペックを設定する。
引張り強度、最大締め付けトルク、
防錆性能(塩水噴霧試験時間) etc. etc.
2. 設計者は、スペックを満たす部品形状・
材質etc.を決定し、ネジの図面を描く。
(スペックも図面に記載することが多い)


FizzBuzzプログラムの仕様
・1,2,…という整数に対し、1,2,…と答える
・ただし、3の倍数のときはFizzと答える
・ただし、5の倍数のときはBuzzと答える
・ただし、3の倍数でかつ5の倍数のときは
Fizz Buzzと答える
いいえ、スペックではありません!
これだけでは、どうやって検証すればよい
か分からないから。
PCの前で「いち」と言うと、プログラムが
「いち」と喋るのかもしれないよ!

FizzBuzzメソッドのスペック(例)
シグネチャ:
public static string FizzBuzz(int n)
動作: 引数nが引数nが
3の倍数? 5の倍数? 返値

false false n.ToString()
true false "Fizz"
false true "Buzz"
true true "Fizz Buzz"

…あれ? ここまで明確にできたのなら、
コードで表現(＝自動化)できるんじゃ!?

FizzBuzzメソッドのスペックをコード化
ただし、すべてのnについて書くと多すぎる
ので、例示に留める。
[TestCase(1, "1")]
[TestCase(2, "2")]
[TestCase(3, "Fizz")]
[TestCase(5, "Buzz")]
[TestCase(6, "Fizz")]
[TestCase(10, "Buzz")]
[TestCase(15, "Fizz Buzz")]
public void FizzBuzzTest(int n, string expected) {
string result = FizzBuzzer.FizzBuzz(n);
Assert.AreEqual(expected, result);
}


あとはスペックを満たすメソッドを書くだ
けだ!
これぞ「テストファースト」!?

いいえ、
テストファーストではありません!!

スペックファーストという当たり前のこと
を、ちょっと自動化してみただけです。


“Test Driven Development: By テストファースト
Example” (2002) 参考訳
In Test-Driven TDDでは、
Development, we ・自動化されたテス
・Write new code トが失敗したときだ
only if an け新しいコードを書く
automated test has ・重複を無くす
failed
・Eliminate duplication たった2つのシンプルな
ルール
These are two simple
rules. リファクタリング


例示でスペックを表現する … … どれだけ
例示したら完璧なのか、分からない!!
例示の仕分け:
コードを育てるのに有用か否か?
例示を追加 → 検証をパス
コードを直さなくてパスするなら、今追加
した例示はコードを育てていない → 不要
例示を追加 → 検証失敗
コードを直さねばならない＝コードを育て
る例示である → 有用

テストファースト＝

スペックファースト＋
(モノ作りでは当たり前の手順)

automated test ＋
(例示によるスペック表現)

例示を最少化するテクニック
※ ただし、不安を解消するためや、ドキュメントの役割
を持たせるため等で、例示を追加しても構わない。


TDDの原理～スペック・ファースト～


TDDの原理～スペック・ファースト

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie TDDの原理～スペック・ファースト

Ähnlich wie TDDの原理～スペック・ファースト (20)

Mehr von Yasuhiko Yamamoto

Mehr von Yasuhiko Yamamoto (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (7)