Loading...

TDDBC仙台

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

大事なことを最初に

Twitter でのさけび

感謝

  • 会場に来てくださった皆様
  • スタッフの皆様
  • 主催者を引き受けてくださった片平さん
  • 岩切さん
  • スポンサーの皆様

自己紹介

自己紹介

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

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

普段やっていること

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

イベントや参加団体等

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

これまで書いたもの

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

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

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

#97prog_ja

これまで書いたもの

  • WEB+DB PRESS vol.35
  • WEB+DB PRESS vol.37
  • WEB+DB PRESS vol.42
  • WEB+DB PRESS vol.49
  • その他いろいろ
  • 『プログラマが知るべき97のこと』
  • WEB+DB PRESS vol.63 (NEW)

WEB+DB PRESS vol.63

#wdpress

gihyo.jpの連載

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

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

東北とのつながり

仙台Ruby会議02

松島牡蠣祭り

東北とのつながり

  • 札幌 Ruby 会議 02
  • 松島牡蠣祭り
  • TDD Boot Camp 仙台 (NOW!)

よろしくお願いします

TDDBCへようこそ

優しくTDDを教えます

ペアプログラミング体験

コードレビュー大会

ふりかえり

TDD Boot Camp 東京

TDD Boot Camp 北陸

TDD Boot Camp 名古屋

TDD Boot Camp 札幌

TDD Boot Camp 福岡

TDDBC札幌2.0

今後の TDD Boot Camp

  • 東京1.5 7/9 (Fix)
  • 東京1.6? 7/31 (企画中)
  • 横浜 11/5 (Fix)
  • 大阪 (9月頃企画中)
  • 四国 (企画中)
  • 岡山 (企画中)
  • 新潟 (企画中)

#tddbc

では始めましょう

TDDの背景

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

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

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

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

テストの再分類

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

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

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

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

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

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

バージョン管理

バージョン管理

テスティング

自動化

テストは柱のひとつ

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

三脚椅子のメタファ

Developer Testingとは

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

xUnitへの流れ

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

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

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

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

自動化されたテスト

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

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

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

化されたテスト

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

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

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

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

良いテストとは

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

クリーンテスト(Uncle Bob)

  • F ast (高速である)
  • I ndependent (独立している)
  • R epeatable (再現性がある)
  • S elf-Validating (自己検証可能)
  • T imely (適時性がある)

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)

応用

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

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

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

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

テストが脆い

テストが遅い

xUnit Test Patterns

現実と戦うための三冊

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

One more book…

GOOS

acts_as_professional

たくさん本を読もう

写経しよう

技術書の「写経」の方法

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

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

TDDと黄金の回転

TDDはスキルです

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

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

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