Loading...

TDDBC東京 for C++

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

大事なことを最初に

感謝

  • 会場に来てくださった皆様
  • 主催者の @imagire さん
  • 会場提供の Nii 様、@mnagaku さん
  • 講師を引き受けてくれた @kaorun55 さん、 @goyoki さん
  • スタッフの皆様

自己紹介

自己紹介

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

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

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

gihyo.jpの連載

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

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

事例

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)

私は何故TDDをするのか

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

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

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

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

今日をふりかえる

ペアプログラミング

コードレビュー

ふりかえり

@kaorun55 さん

@kaorun55 さん

  • 「自然とTDDのような何かをやっている自分がいる」
  • しつけ=躾
  • 美しい開発者は美しい習慣から
  • 資料は既に slideshare にアップされています

@goyoki さん

@goyoki さん

  • TDD 実践/学習のネクストステップ
  • 仕様ベースの網羅/実装ベースの網羅
  • テスト設計の重要性
  • 資料は後ほど修正版がアップされる予定です

会場を回って

  • どこまで事前設計するべきか (ENUF)
  • リファクタリングのタイミングとやめどき
  • テスト設計について
  • private のテスト
  • assertion が縦に並んだときは
  • Parameterized Test
  • テストのスキップ

きっと誰かが解いている

知識のインデックスをつくる

  • きっと誰かが解いている
  • 巨人の肩に乗る
  • 知っているのはズルではない
  • 検索キーワードにたどり着く力

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

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

祈りではなく自信を

たくさん本を読もう

TDDはスキルです

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

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

写経しよう

技術書の「写経」の方法

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

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

TDDと黄金の回転

acts_as_professional

ブログに書くまでが #tddbc です

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