Loading...

TDDのこころ

和田 卓人 (a.k.a id:t-wada or @t_wada)

Press key to advance.

Slides controls, press:

  • and to move around.
  • Ctrl/Command and + or - to zoom in and out if slides don’t fit.
  • T to change the theme.
  • H to toggle syntax highlight.

自己紹介

自己紹介

  • 名前 : 和田 卓人(わだ たくと)
  • ブログ : id:t-wada
  • メール : takuto.wada@gmail.com
  • Twitter : @t_wada
  • タワーズ・クエスト株式会社 取締役社長

./../../images/TQ_LOGO_SMALL.png

これまで書いたもの

  • WEB+DB PRESS vol.35
  • WEB+DB PRESS vol.37
  • WEB+DB PRESS vol.42
  • WEB+DB PRESS vol.49
  • 『プログラマが知るべき97のこと』

プログラマが知るべき97のこと

gihyo.jpの連載

  • 「動画で解説」和田卓人の"テスト駆動開発"講座
  • http://gihyo.jp/dev/serial/01/tdd
  • 全20回すべて動画付き解説
  • ニコニコ動画でも見れます

./../../images/gihyo-tdd-icon.png

イベントや参加団体等

  • Developers Summit (通称デブサミ)
  • java-ja
  • asakusa.rb
  • xUnit Test Patterns 読書会
  • TDD Boot Camp

TDD Boot Camp 東京

TDD Boot Camp 北陸

TDD Boot Camp 名古屋

普段やっていること

  • 商用 Rails プラグイン(自社製品)の開発
  • コンサルティング
  • TDD の啓蒙
  • Twitter, facebook

よろしくお願いします

TDDの背景

「テスト」という言葉の混乱

  • 「テスト」という言葉が指すものがバラバラ
  • 単体、ユニット、結合、機能、システム、…
  • たくさんあるけど、何がなにやら…単体テストとユニットテストって同じもの?
  • テスト範囲による分類には曖昧さ、限界がある

再分類のための視点を探す

  • テストは品質保証のため? 動作確認のため?
  • 目的に戻って考えてみよう
  • 誰が、何のためにテストを行うのか という視点

テストの再分類

「テスト」という言葉から思い浮かべるものを…

DeveloperTestingCustomerTestingQATesting
開発者顧客(のロール)品質保証担当者(のロール)
開発促進進捗管理品質保証

「誰が、何のために」という視点で再分類する

現代ソフトウェア開発の三本柱

  • バージョン管理
  • テスティング
  • 自動化

バージョン管理

バージョン管理

テスティング

自動化

三本柱 => 三脚椅子

テストは柱のひとつ

  • バージョン管理
  • テスティング
  • 自動化

Developer Testingとは

  • プログラマの
  • プログラマによる
  • プログラマのための
  • プログラムとしてのテスト を書き ながら
  • 開発を行っていく手法

xUnitへの流れ

それまでも自動テストの仕組みはあった

  • テスト用のmainメソッド
  • テスト実行用バッチスクリプト

テスティングフレームワークの登場

  • xUnitファミリー
  • SUnit, JUnit, NUnit, PHPUnit,…
  • テスト方法が共有され、キャズムを越えた

自動化されたテスト

テスティングフレームワークがもたらしたもの

  • テスト記述方法の共通化
  • テスト実行方法の共通化

テストを書いた人でなくとも、同じようにテストを実行できるようになった

化されたテスト

テスティングフレームワークがもたらしたもの

  • テスト記述方法の共通化
  • テスト実行方法の共通化

テストを書いた人でなくとも、同じようにテストを実行できるようになったということは…

  • コンピュータでも人と同じように実行可能
  • テストの自働化へ

テストする内容

Right-BICEP

  • Right (結果が適切か)
  • B oundary (境界条件)
  • I nvert (逆の関係を確かめる)
  • C ross-Check (クロスチェック)
  • E rror conditions (エラー条件)
  • P erformance (パフォーマンス)

境界条件テストのコツ

CORRECT

  • C onformance (フォーマットなどの適合性)
  • O rdering (データの順序、位置)
  • R ange (値域の範囲)
  • R eference (参照、事前/事後条件)
  • E xistence (存在。null、空、0)
  • C ardinality (数。0-1-nの法則)
  • T ime (時間。相対/絶対/並行)

良いテストとは

A-TRIP

  • A utomated (自動化されている)
  • T horough (徹底している)
  • R epeatable (何回でも実行可能)
  • I ndependent (独立している)
  • P rofessional (プロのコード)

TDDとは?

『テスト駆動開発入門』

二つの道がある

TDDのサイクル

  1. テストを書き
  2. そのテストを実行して失敗させ(Red)
  3. 目的のコードを書き
  4. 1で書いたテストを成功させ(Green)
  5. テストが通るままでリファクタリングを行う(Refactor)
  6. 1~5を繰り返す

TDDと黄金の回転

TDDのこころ

一つずつ、少しずつ

ひとりずつ仕留める

すばやくまわす

自分が最初のユーザ

道具にこだわる

不安をテストに

祈るのではダメ

安心して飛び込む

なぜTDDをするのか

  • 私たちは完璧なプログラマではない
  • 最初から思い通りにコードが書けるほど、私たちは賢くない
  • 最初から思い通りに動作するほど、対象は単純ではない
  • 素早く対象に近づき、フィードバックを得て方向修正をしながら開発を行う必要があるから

テストは目的ではなく手段

Developer Testing, TDD にソフトウェア工学的なメリットはいろいろあるけれど、最大の理由は工学的なものではない。最大の理由は心理的なもの

  • 即座にフィードバックを得るため
  • 書いたコードに自信を持つため
  • これから書くコードに自信を持つため

TDDの真の目的

健康

変化に対応できるのは健康体の コード

変化に対応できるのは健康体の チーム

不安の克服 健康の維持

デモ

FizzBuzz問題

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。

http://tickletux.wordpress.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/

http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm

ペアプログラミング

事実、ペアプロは楽しい。

コードレビュー大会

事例

TDD導入効果(MS, IBM)

IBM DriverMS WindowsMS MSNMS Visual Studio
ソースコードサイズ (KLOC)41.06.026.0155.2
テストコードサイズ (KLOC)28.54.023.260.3
欠陥密度(※1)0.610.380.240.09
増加したコード実装時間(※2)15~20%25~35%15%25~20%

(※1)TDDを採用していない類似プロジェクトでの欠陥密度を1としたときの欠陥密度

(※2)TDD採用により増加したコード実装時間(管理者の見積による)

N. Nagappan, M. E. Maximilien, T. Bhat and L. Williams: Realizing quality improvement through test driven development: results and experiences of four industrial teams, Journal of Empirical Software Engineering, vol. 13, pp. 289-302 (2008)

TDD導入効果(エリクソン他)

TDDを実施した場合に報告されている知見

  • 機能テストでの不具合検出数が18%削減された
  • コーディング(実装)の時間が16%増えた
  • テストのカバレッジが大きくなった

被験者を対象としたアンケート

  • 96%の被験者がデバッグの工数を減らすと感じた
  • 88%の被験者が要求が洗練されると感じた
  • 92%の被験者がコードの品質を上げると感じた
  • 50%の被験者が開発工数を 減らす と感じた

Boby George, a and Laurie Williams: A structured experiment of test-driven development, Journal of Information and Software Technology Vol. 46, No. 5, p. 337-342(2004)

おわりに

acts_as_professional

たくさん本を読もう

TDDと黄金の回転

TDDはスキルです

テストやTDDはスキルです。つまり…

  • 才能ではなく、習得可能です
  • 量は質に転化します
  • 写経!!

ご清聴ありがとうございました

feedback

  • プロトタイピング開発との相性はどうか
  • mock の使いどころやバランス
  • 品質指標のようなものはあるか
  • 自分のためのカバレッジと、ひとのためのカバレッジは違う

todo

  • きのこアイコン
  • ロング巻物
  • 四象限モデルを自前で
  • Web Fonts
  • 技術書の「写経」の方法 http://twitter.com/t_wada/status/9000231741
  • QUnit を組み込む
  • Twitter Streaming API と websocket を使う
  • ボトムアッププログラミング, Lisp, Smalltalk
  • Right-BICEP
  • A-TRIP
  • テスト技法ドリル
  • Kent Beck の Stack のやつ
  • Neal Ford の Stack のやつ
  • js test driver
  • きのこ本のテストのこと
  • プロセスと非依存であること

応用

テストの無いコードが既にたくさんある

レガシーコード改善ガイド

既にデータの入ったデータベースがある

データと戦う

  • データベースもリファクタリングする
  • 慎重さ、周到さが必要
  • 長いリファクタリング期間

データベースリファクタリング

テストが脆い

テストが遅い

xUnit Test Patterns

現実と戦うための三冊

  • レガシーコード改善ガイド
  • データベースリファクタリング
  • xUnit Test Patterns

お題 : LRU Cache

一定の数に達したら使われていない順に要素が削除されていく Map のような入れ物を作りたい。 このため、 Last Recently Used (LRU) Cache を今回作成する。 キャッシュの最大サイズに達したときに、最も使われていないデータから順に消される Map のような仕組みがほしい。

例 :サイズが 2 の LRU Cache の場合

# 一つも使われてない場合は最初に追加したものから消える
lru.put(“a”,“dataA”); 
lru.put(“b”,“dataB”); 
lru.put(“c”,“dataC”); 
lru.get(“a”); #=> null 
# get されたら使われたとみなす
lru.put(“a”,“dataA”); 
lru.put(“b”,“dataB”); 
lru.get(“a”); #=> “dataA” 
lru.put(“c”,“dataC”); 
lru.get(“b”); #=> null 

仕様変更その1

  • 「いやー和田君、こないだの LRU Cache、だっけ?」
  • 「はい」
  • 「ステキなんだけど、もうちょっと便利にしたいなぁ」
  • 「はい (なんだろう…)」
  • 「キャッシュサイズをあとから変えたいんだ」
  • 「えっ」
  • 「キャッシュサイズ減らしてもちゃんと動いてほしい」
  • 「えっ」

仕様変更その2

  • 「いやー和田君、こないだの LRU Cache、だっけ?」
  • 「はい」
  • 「ステキなんだけど、もっと意図を汲んで欲しいんだ」
  • 「はい (なんだろう…)」
  • 「一定時間経ったデータも消えて欲しいんだ」
  • 「えっ」

仕様変更その3

  • 「いやー和田君、こないだの LRU Cache、好評だよ」
  • 「ありがとうございます」
  • 「ステキなんだけど、もっと意図を汲んで欲しいんだ」
  • 「はい (なんだろう…)」
  • 「同時アクセスが結構あるのでスレッドセーフがいいなぁ」
  • 「えっ」