Loading...

TDDBC福岡2

和田 卓人 (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.

大事なことを最初に

感謝

  • 主催者の @pocketberserker さん
  • スタッフの皆様
  • 会場に来てくださった皆様(今日はどこから?)

自己紹介

自己紹介

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

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

普段やっていること

  • 商用 Rails プラグイン(自社製品)の開発
  • テスト技術のコンサルティング
  • レガシーコード改善のコンサルティング
  • アジャイルソフトウェア開発のコンサルティング
  • TDD の啓蒙
  • Twitter, facebook

これまで書いたもの

  • WEB+DB PRESS vol.35 (TDD)
  • WEB+DB PRESS vol.37 (リファクタリング)
  • WEB+DB PRESS vol.42 (REST)
  • WEB+DB PRESS vol.49 (DRY)
  • その他いろいろ
  • WEB+DB PRESS vol.63 (テストコード)
  • 『プログラマが知るべき97のこと』

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

gihyo.jpの連載

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

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

よろしくお願いします

TDDBCへようこそ

優しくTDDを教えます

ペアプログラミング体験

コードレビュー大会

ふりかえり

#tddbc

では始めましょう

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

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

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

バージョン管理

バージョン管理

テスティング

自動化

テストは柱のひとつ

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

三脚椅子のメタファ

TDDを語る前に

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

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

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

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

テストの再分類

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

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

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

Developer Testingとは

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

TDDとは?

『テスト駆動開発入門』

二つの道がある

TDDのサイクル

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

TDDと黄金の回転

TDDのこころ

一つずつ、少しずつ

ひとりずつ仕留める

すばやくまわす

自分が最初のユーザ

道具にこだわる

不安をテストに

祈るのではダメ

テストが命綱

なぜTDDをするのか

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

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

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

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

TDDの真の目的

健康

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

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

不安の克服 健康の維持

たくさん本を読もう

TDDはスキルです

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

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

写経しよう

技術書の「写経」の方法

  1. ローカルで使える SCM を用意
  2. 「ほんたった」などで対象の本を固定
  3. ひたすらサンプルコードを写して実行
  4. 実行するたびにコミット(コミットログにページ番号を含める)
  5. 疑問点があったらコミットログや本に書き込む
  6. 章ごとにタグを打つ

(「技術書の写経の方法」でググると出てきます)

TDDと黄金の回転

acts_as_professional

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

Q & A

事例

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)

応用

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

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

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

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

テストが脆い

テストが遅い

xUnit Test Patterns

現実と戦うための三冊

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

One more book…

GOOS

#goos_jp