TDDBC in TokyoにUst参戦してきた。

TDDBC in TokyoにUst参戦してきました。(と言っても録画でですが…)

ATNDに登録されてから一瞬で参加枠が埋まり、競争率300%overのこちらのイベントでしたが、Ustで配信して頂いたお陰でサテライトながら参加することが出来ました。すごくタメになる内容だったのでエンジニアの人は絶対に見るべき。こちらに動画が上がってます。

というわけで、自分のためにUstの内容をまとめます。ブログに書かないと覚えておけないので。。内容が濃く、いっぺんに処理しきれないので、今回は@t_wadaさんの基調講演に絞ってまとめます。LTはまた別途。。

TDDBC基調講演内容まとめ

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

  • バージョン管理 バージョン管理システムをつかいこなして、ソフトウェア開発の歴史を自信を持って管理していく。 ソフトウェア開発においてバージョン管理がないと死亡確定。
  • テスティング 自動でテストを行うテストコードを書きながら開発を行う。 TDDBCで講演するのはこの部分。
  • 自動化 jenkins, rake, ant, シェルスクリプトなどを用いて、人間がなるべく単純作業をやらずに済むようにする。 人間は人間にしかできないことに時間を使う。

ソフトウェア開発の三本柱として上記の3点を上げていました。また、イメージとしてはそれぞれが三脚の一つであり、どれか一つが欠けても良くないとも。うちの会社なんて、3つとも欠けてる気がするんだけど、それでもなんとか開発が出来ているのは奇跡かもしれない。。

テストの目的を考える

ユニットテスト、単体テスト、結合テスト、機能テスト、システムテスト…、テストを指し示す言葉は色々ありすぎて混乱する。テスト範囲による分類には、認識のずれや重複部分が出てきて、限界がある。そのため、誰が何のためにテストを行うのかという観点でテストを分類する方が良い。

テストを再分類すると、以下の3つに分けられる。

  • Developer Testing 開発者が開発促進のために行う。TDDの目的がこれ。
  • Customer Testing 顧客が進捗管理のために行う。受入れテストなどを指す。
  • QA Testing 品質保証担当が品質保証のために行う。性能・セキュリティ・保守性などの非機能要件をテストする。

動作するきれいなコードを書くには

  • きれいな設計をしてそれをコードに落とし込む きれいな設計を追求するとコードを書くところに辿り着けない(完璧主義の呪い)
  • 動作するコードを書いて、それをきれいにしていく(リファクタリングしていく)という手法もある コードを書いてみて初めて気づくこともある。

前者はウォーターフォール開発、後者はアジャイル開発と置き換えるとイメージ沸きやすい。

TDDのサイクル

  1. テストを書く
  2. そのテストを実行して失敗させる
  3. そのテストを突破する(最低限の)コードを書く
  4. テストを成功させる
  5. テストが通るままでリファクタリングを行う
  6. 1~5を繰り返す。

上記をTDDの黄金の回転として回していく!

TDDのこころ

  • 1つずつ少しずつ 大きな問題を達成可能な複数の小さな問題に分割する
  • ひとりずつ仕留める 多くのものを一度に相手にしない
  • すばやくまわす 1つの問題に時間をかけない
  • 自分が最初のユーザ 自分が作ったコードを最初に使うのは自分。利用者視点でコードを書く。
  • 道具にこだわる 自分のパフォーマンスを最大限引き出すために、エディタやツールの使い方をマスターし、カスタマイズしていく。
  • 不安をテストにする getter/setterなどのためにテストを書かない。不安を解消するため、自分のためにテストを書く。
  •  祈らない テストしていないコードを祈りながらリリースするようなことはしない。
  • テストが命綱 テストがあれば品質に自信を持てる。いざ飛び込むときに命綱を作っているのでは遅い。

このあたりは、テスト駆動開発チートシート - やさしいデスマーチ に綺麗にまとめられていますね。

なぜTDDをするのか

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

TDDはソフトウェア工学的にも様々なメリットがあるが、最大のメリットは心理的なもの。

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

不安を克服し、きれいなコードを維持していくことがTDDの目的。

TDDの導入事例

以下2つのTDDに関する論文が紹介されていました。

テスト駆動開発(TDD)の事例 - IBMとMS 計4プロジェクトを紹介した論文

TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社

ざっくり言うと、コード実装時間が2割増えて、バグは半分に減る。また、デバックの時間の大幅な短縮により、実装時間が増えているにも関わらず開発工数も短くなる可能性がある。これだけ読むとTDDを導入しない理由がないですね。

応用編

とは言っても、既にテストの無いコードがたくさんある。。

とは言っても、データの入ったデータベースがある。。

とは言っても、一部の変更を加えただけで、テストの過半数が通らなくなる。。(実装に依存しているテストが大量にある)

現実と戦うための3冊を読もう!

そしてもう1冊…

Growing Object-Oriented Software, Guided by Tests

2冊目のTDDバイブルになるかも?

プロのプログラマたるもの…

プロのプログラマとしての嗜みはテストを書くこと。プロならば、テストを書かなきゃいけない。

そして…

  • 本をたくさん読もう!
  • 写経しよう!

写経の仕方はこちら。

最後に

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

  • 才能ではなく、習得可能
  • 量は質に転化する

誰でもできるようになるんだよー!

TDDBC基調講演で紹介された書籍まとめ

読んでない本が結構あるので少しずつ読んでいく。。

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

WEB DB PRESS Vol.63

レガシーコード改善ガイド (Object Oriented SELECTION)

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

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))