わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 1/26

TDD道場

2014年2月15日

わんくま同盟名古屋勉強会 #30

TDDやってみよう!

biac

名古屋ソフトウェアセンター

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 2/26

自己紹介• 著書– 「速攻入門 C#」 (2012/3)

技術評論社、共著

– 「ソフトな彼女とハードな彼氏。」(2012/3) アジャイルマインドvol.1 掲載

• 記事– 連載 「C#でTDD入門」

CodeZine

– 週刊連載「WinRT/Metro Tips」@IT - .NET開発者中心…etc.

biac (山本 康彦)

BluewaterSofthttp://www.bluewatersoft.jp/

• 名古屋大学工学部(修士)• HONDA R&Dで自動車設計• 1994～ ソフトウェア業界• 2012～ BluewaterSoft

ソフトウェア開発

Windows 8 Metro Style App.Windows Phone 8…Windows系の最新技術

TDD(コーディング技法)の普及

著作

2013/7

すまんm(_`_)m

この1年、すっかりサボってました

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 3/26

Test

Driven

Development

テスト駆動開発

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 4/26

TDD – テスト駆動開発

・「テスト」と言ってるけど、TDDは品質保証テストじゃない。

・「開発」と言ってるけど、TDDは開発プロセスじゃない。

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 5/26

TDDの考案者

Kent Beck の説明“Test Driven Development: By Example” (2002) より。

We drive development with automated tests,

a style of development called Test-Driven

Development (TDD).

「

」

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 6/26

具体的には?“Test Driven Development: By Example” (2002) より。

In Test-Driven Development, we・Write new code only if an automated test has failed・Eliminate duplicationThese are two simple rules.

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 7/26

Test

Driven

Development

＝ 自動化されたテストを使って開発を駆動するスタイル

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 8/26

大事なことなのでもう1度

「自動化されたテスト」…を作ってからコードを書くのだ。

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 9/26

そうは言っても…

「テストファーストってよくわからない orz」

よろしい、もっと厳格なルールを与えよう!

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 10/26

TDD 3原則 by Robert C Martin

1.You are not allowed to write any production code unless it is to make a failing unit test pass.2.You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.3.You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

ArticleS.UncleBob.TheThreeRulesOfTdd (2005) より。※ 実質は「テストファースト 3原則」

1. 失敗するユニットテストを成功させるためにしか、プロダクトコードを書いてはならない。

2. 失敗させるためにしか、ユニットテストを書いてはならない。コンパイルエラーは失敗に数える。

3. ユニットテストを1つだけ成功させる以上に、プロダクトコードを書いてはならない。

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 11/26

TDD 3原則に従うとテストケース数は少なくなる

テストケース数TDD: メソッドの振る舞いを規定できる最小限品質保証: 品質が保証できると思えるだけ沢山

大事な事なので2回 - TDDは品質保証テストじゃない!

「三角形問題で必要なテストケース数」参照。1～2桁違う。

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 12/26

CM

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 13/26

TDD Advent Calendar

• http://qiita.com/advent-calendar/2013/tddadventjp/participants

• 「tdd カレンダー 2013」でぐぐる(Bingじゃ出ない)

• twitterハッシュタグ#TddAdventJp

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 14/26

NUnit の全貌

• C#やVBで使われるユニットテスト フレームワークNUnitの使い方

• http://codezine.jp/article/detail/6518

• 「NUnitの全貌」でぐぐる(Bingじゃトップに出ない)

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 15/26

今年のテーマ

•テストファーストに必要なスキルがある。それは…

メソッドの外部設計

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 16/26

外部設計≠概略設計

• 《愚痴》いちいちこの話が必要になるソフトウェア開発業界って… orz

外部設計 external design・外観

メソッドではシグネチャの決定

・反応メソッドでは、引数に対する返値や副作用。OOP風にいえば、「メッセージに対する(外部から見た) 振る舞い」

概略設計 (概要設計)outline designhigh level design

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 17/26

外部設計⇨ TDD

• メソッドの外部設計が出来て、初めてTDDをすることができます。

• メソッドの外部設計は、頭の中に構築するだけだったり、ToDoリストとして書き出したり。

外部設計 external design・外観

メソッドのシグネチャを決定

・反応メソッドの、引数に対する返値や副作用。

テストファースト外部設計からひとつずつ取り出して、ユニットテストに変換

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 18/26

外部設計⇨ TDD の例

• ごく簡単な例

• 外部設計を決めてあるから、ユニットテストが書ける

外部設計 external design・外観

public int Add(int x, int y)

・反応引数xとyの和が返される副作用は無し

ユニットテスト

Assert.AreEqual(3, Add(1, 2))

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 19/26

入出力表

• 状態に依存しないメソッドの外部設計には、入出力表が便利

• Decision Table (決定表, JIS X 0125) とは違う(決定表では、メソッドの出力ではなく、メソッドの動作を記述する)

外部設計 external design・外観

public int IsEven(int n)

・反応引数が偶数のときtrue、そうでないときはfalseを返す。

《入出力表で示す》

入力(引数 n)

出力(返値)

偶数 true

奇数 false

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 20/26

入出力表

• 入出力表の入力は、全パターンを網羅するように書く

• 引数ごとに入力の列を作るだけだと、分かりにくいこともある。この例は、単偶数(半偶数)の判定メソッド

外部設計 external design・外観

public int IsSinglyEven(int n)

・反応引数が2で割り切れるが4では割り切れないときtrue、そうでないときはfalseを返す

入力(引数 n)

出力(返値)

2で割り切れるが4では割り切れない数

true

2で割り切れないか、2でも4でも割り切れる数

false

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 21/26

入出力表(改)

• 入出力表の入力列は、引数の性質を分類するものでもいい。

• 大切なことは、入力の全パターンを、いかに分かりやすく表現できるか。

外部設計 external design・外観

public int IsSinglyEven(int n)

・反応

入力 (引数 n) 出力(返値)2で割り切れる 4で割り切れる

YES YES false

YES NO true

NO ANY (YES or NO) false

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 22/26

入出力表(改)

• 単偶数の入出力表ができたので、テストファーストする

外部設計 external designpublic int IsSinglyEven(int n)

#入力 (引数 n) 出力

(返値)2で割り切れる 4で割り切れる

(1) YES YES false

(2) YES NO true

(3) NO ANY false

テストファーストやりやすそうなケースから実施していくAssert.IsFalse(IsSinglyEven(1)); // (3)Assert.IsTrue(IsSinglyEven(6)); // (2)Assert.IsFalse(IsSinglyEven(4)); // (1)

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 23/26

演習

• FizzBuzzのコアとなるメソッドの外部設計をせよ。

• ただし、作るメソッドは状態に依存しないものとする。

FizzBuzz『最初のプレイヤーは「1」と数字を発言する。次のプレイヤーは(中略)次の数字を発言していく。ただし、3で割り切れる場合は 「Fizz」、5で割り切れる場合は 「Buzz」、両者で割り切れる場合は 「Fizz Buzz」を数の代わりに発言しなければならない。』(Wikipediaより)

外部設計 external design・外観 public ??? SayFizzBuzz(???)

・反応 ???

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 24/26

演習タイム

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 25/26

回答例

• 発言の順番(1,2,3,…)を入力とし、発言する文字列を出力とした

外部設計 external design・外観

public string SayFizzBuzz(int n)

・反応

入力 (引数 n) 出力(返値)3で割り切れる 5で割り切れる

YES YES "Fizz Buzz"

YES NO "Fizz"

NO YES "Buzz"

NO NO n.ToString()

わんくま同盟 名古屋勉強会 #30 – TDD道場 #18 26/26

おしまい

まとめ・テストファーストの前に

外部設計をする

・今回は、状態に依存せず副作用も無いシンプルなメソッドの外部設計に、入出力表を用いた