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

biacBluewaterSoft

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開発者中心

WebTDD.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 called Test-Driven Development (TDD).

参考訳

自動化されたテストを使って、私たちは開発を駆動する。それがテスト駆動開発(TDD)と呼ばれる開発のスタイルだ。


× テスト○ 自動化されたテスト

× テストが駆動する○ 私たちが駆動する


In Test-Driven Development, we・Write new code only if an automated test has failed・Eliminate duplication

These are two simple rules.

参考訳

TDDでは、・自動化されたテストが失敗したときだけ、新しいコードを書く・重複を無くす

たった2つのシンプルなルール


テストファースト

リファクタリング

レッド / グリーン / リファクタ「黄金の三角形」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が3の倍数?

引数nが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);

}


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

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

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



In Test-Driven Development, we・Write new code only if an automated test has failed・Eliminate duplication

These are two simple rules.

参考訳

TDDでは、・自動化されたテストが失敗したときだけ新しいコードを書く・重複を無くす

たった2つのシンプルなルール


テストファースト

リファクタリング

例示でスペックを表現する … … どれだけ例示したら完璧なのか、分からない!!

例示の仕分け:コードを育てるのに有用か否か?

例示を追加 → 検証をパスコードを直さなくてパスするなら、今追加した例示はコードを育てていない → 不要

例示を追加 → 検証失敗コードを直さねばならない＝コードを育てる例示である → 有用


テストファースト＝

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

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

例示を最少化するテクニック

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


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


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

Technology

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