圧倒亭グランパのブログ

30年後の自分にもわかるように書くブログ

テスト駆動開発の勘違いを見直す

「新訳版 テスト駆動開発」を読み終わり、テスト駆動開発(以下、TDD)について考え方が変わったのでまとめます。

 

目次

 

勘違い

自分もよくある勘違いをしていました。TDDは以下のようだと思っていました。

  • テストを先に書く
  • テストを先に書いていれば設計が良くなる

これは下記の記事でも書きました。

at-grandpa.hatenablog.jp

このような考え方については、付録Cで言及されています。なぜ自分はこのような勘違いを起こしたかというと、

書籍や一次情報にまでアクセスせず、伝聞や自分たちの解釈で TDD/BDD の名前やツールを使う人が増えました。

引用元: 新訳版 テスト駆動開発

と付録Cに書かれているように、まさにその通りでした。この勘違いが読了後には変わりました。

 

TDDが解決している課題から考えてみる

最近は「技術と課題の結びつき」にフォーカスを当てて勉強しています。

at-grandpa.hatenablog.jp

その観点からみると、TDDは以下の二つの「課題」を解決してくれると考えています。

  • 開発中に「うまく動作するのか?」という不安
    • => TDDで「不安のコントロール」をすることで解決
  • 知らず知らずのうちに良くない設計になってしまう
    • => TDDの「設計のカナリア」という特徴を利用して解決

つまり、この二つの課題を感じたらTDDを行って解決しましょう、ということです。一つずつ見ていきましょう。

 

不安のコントロール

TDDは、レッド・グリーン・リファクタリングというサイクルを細かく回すことで不安をコントロールします。グリーンバーが表示されることで精神的な負担を減らし、前に進んでいる感を感じることができます。レッドバーが表示されたらリファクタリングをしてグリーンバーにしましょう。グリーンバーは心の拠り所です。

もし、グリーンバーにたどり着けず、道に迷ったらどうしましょう。大丈夫です。TDDはそこもカバーしています。「歩幅」を調整しましょう。一旦前のグリーンバーに戻り、次はさらに細かいステップで開発を進めましょう。この「歩幅の調整」に関しては ajitofm 13: Test Driven Development でも和田さんが言及されていますので、一度聞いてみてはいかがでしょうか。

ajito.fm

この「不安のコントロール」に関しては自分も体感していました。勘違いTDDでもグリーンバーで安心を得ていたのは事実です。

そして、自分にとって一番の気付きは次の「設計」に関する項目です。

 

設計のカナリア

テストは設計から立ち上る悪臭を敏感に察知して教えてくれる、炭鉱のカナリアだ。

引用元: 新訳版 テスト駆動開発

いわゆる「炭鉱のカナリア」とは、「毒ガスが発生していると、常に鳴いているはずのカナリアが鳴き止む」ということから「異常検知」として用いられてきました。TDDでのテストは「設計のカナリア」となります。TDDを進めていて違和感を感じた時、それは異常の知らせです。違和感の例としては以下のようなものが挙がっていました。

・前準備に要するコードが長い
・前準備コードの重複

引用元: 新訳版 テスト駆動開発

これらの違和感が現れた時、設計を見直しましょう。(おそらく、違和感の種類はこれら以外にもあると思います。)

この「異常検知」という側面は、今までのTDDのイメージにはありませんでした。この本を読み終えて、「あぁ、こういうことだったのか」と一番納得した部分です。

 

「TDDは良い設計を生むものではない」の理解

以前の 記事 で「TDDは良い設計を生むものではない」ということを書きましたが、最後まで読み切ったことでその解釈が明確になりました。TDDは「異常検知システム」だからです。「設計改善法」ではないのです。異常がわかったあと、そこからどう修正するかは個々人の力量にかかっています。エンジニアリングの腕の見せ所です。

とはいえ、「TDDで設計が良くなるわけではないのか。残念。」という悲観的な気持ちは一切ありません。TDDの異常検知機能はそれだけで莫大な恩恵があるので、今回知れたことは非常に大きいです。また、次に勉強すべき点が「リファクタリングのパターン」だということもハッキリしました。異常がわかったあとの「次の一手」を増やしましょう。本書にも幾つかのパターンが示されていましたが、それ以外のパターンも身につけ、現場で使えるようにしたいと思います。

 

まとめ

今回はTDDの勘違いを見直しました。TDDは以下の二つの機能で開発を支援します。

特に後者は「異常検知機能」であり、良い設計を生むものではありません。異常が検知されたら、次は「どうリファクタリングするか」が大事であり、そこは個々人の知識に委ねられています。つまり、次に勉強すべき方向は「リファクタリングのパターン」ということになります。

とりあえずまたリポジトリを作って、リファクタリングのパターンを実コードで学んでいこうと思います。

 

今回のような考え方は、本書を読んでの自分なりの解釈です。付録Cにもあった通り、教条主義的な考え方に陥らないように気をつけたいと思います。指摘点やご意見等がありましたら、 Twitter - @at_grandpa までメンションいただけたら幸いです。というか、「TDDについて語る会」的なものに参加したいですね。