The Dabsong Conshirtoe

技術系の話を主にします。

DevLove2012に行ってMyTDDを見直そうと思った

DevLove2012に行って来ました。
登壇者の皆さん、スタッフの皆さん、参加者の皆さんお疲れ様でした!

さて、2日間ぶっ通しでたくさん中身の濃いセッションが行われましたが、僕にとって今回のDevLoveは自分がやってきたTDDを見直すきっかけとなりましたので、覚書としてブログに起こしておきます。

TDDとの出会い

僕が開発でTDDを取り入れるようになったのは今年の9月。
当時テストというと、単体すっとばして結合をやったりしてました。単体テストもせいぜいインタプリタでちょろっと動かす程度でした。
(それでも大きな問題なく開発できてましたが)

ところで、僕には以前から「美しいコードを書きたい」という思いがあります。
リファクタリングが美しいコードを書く有効な手法だと感じているのですが、風の噂で「TDDをやるとリファクタリングがやりやすくなる」みたいな話を小耳に挟んだので、試しにケント・ベック本を読んでみて、「これは良さげ!」と感じTDDを取り入れてみました。
確かにテストがあればリファクタの結果デグレしてないってことを保証できるので、コードを綺麗にするスピードと既存のコードに手を入れる安心感が高まると感じたんです。

My TDD

私のやったTDD。
早速テストファースト原則を破ります。なぜなら、「テストでリファクタをやりやすくしたい」っていう目的なら初めにテスト書く必要なんてないと思ったからです。リファクタしよう!って思ったときにその箇所のテスト書けば済む話ですから、順序なんてどうでも良いって思ってました。
勿論、テストを最初に書くことでインターフェースが洗練するって話も本では読みましたが半信半疑でした。

My TDDの結果・・・

期待通り、リファクタが捗りました。インタプリタで手打ちして確認してたのが馬鹿らしくなりましたね。
ただ、テストが書きづらいケースなんかも出てきて、これは設計が汚いか、テストが書きやすくない設計か、その両方かって疑問を持ったのが最近です。
テストが書きづらいとリファクタが進みません。テストのメンテナンスコストも高まります。テストを書きやすくするにはテストを先に書くのがよさそうだ。これはテストファーストってやっぱ大事かもと思ったわけです。

DevLoveで語られたTDD

さて、今回のDevLoveでは以下の3つのTDD関連セッションに参加しました。

  1. 「テストに開発をもっと駆動させたい」(諸橋恭介さん)
  2. 「世界を少しだけ前に動かすということ」(和智右桂さん)
  3. 「愛せないコードを書くには人生はあまりにも短い」(和田卓人さん)

それぞれのセッションで感じたことを簡単にまとめます。

諸橋さんのセッション

印象的だったのは、「テストは将来のための高い保険料を払うようなものではない」ってとこ。「テストによるリファクタのしやすさ向上や品質向上は副次的効果」とバッサリでした。
自分はTDDはリファクタありきだと思っていたのでちょっとショック。諸橋さんは、テストをまさに今現在の開発を駆動させるために使ってるんだなと感じました。

講演資料
devlove2012-let-yor-test-drive-dev-more // Speaker Deck

和智さんのセッション

GOOSという本の訳本(実践テスト駆動開発)を出したそうで、ケント・ベック本に続くバイブルとか言われてるそうです。
モックについて語らてるらしいです。モックってすげー便利だけどなんだかうまく使えてない感が激しかったので(モック差し込み周りのコードがゴチャゴチャしやすい)、藁をも掴む思いで読んでみようとおもいます!
(「モックは設計の手法として価値がある」ようなことも仰ってましたので余計に気になりました)

講演資料
世界を少しだけ前に進めるということ

和田さんのセッション

プログラミングの楽しさの源泉は動いたときの喜び。それを思い起こさせてくれる技術としてTDDが有効だとの事。確かに。
このセッションでは、Unix、REST、SQLといった長年生き残ってきた技術から学ぶ、という話が印象的でした。
これらの技術群に共通することは以下であると仰ってました。

  • 少ないインターフェース
  • 実装に依存しない
  • 再利用が時間を跨いでいる

この特徴の結果、以下の事が学べます。

  • シンプル、それぞれのモジュールが直交している
  • クリーンでリーダブル
  • 力技ではなく必要な抽象度、穏当なコード

講演資料
愛せないコードを書くには人生はあまりにも短い

これからのMy TDD

これらのセッションから感じたことは、TDDはリファクタをやりやすくしたり品質を保証するだけでなく、設計を美しする、更には仕事を楽しくするっていう力を秘めてるんではないかということです。
今自分がやってるTDDは、「テスト駆動開発」というか「テスト駆動リファクタリング」であったわけです。話を聞くに、テストを書くことが、どんな設計にするか考える事にも役立つというのは本当っぽいので、とりあえず愚直にTDDの原則(テストファースト)に立ち返ってコードを書いてみたいと思います。「守破離」の「守」って大事ですね。

テスト駆動開発入門

テスト駆動開発入門

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/09
  • メディア: 単行本
  • 購入: 44人 クリック: 1,022回
  • この商品を含むブログ (154件) を見る

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)