kenju's blog

About Programming and Mathematics

新訳版『テスト駆動開発』を読んだ

テスト駆動開発

テスト駆動開発

旧訳版も読んだことがなかった。この本が非常に優れているのは、すごく細かいステップを経ながら、あたかも著者とペアプログラミングをしているかのように手取り足取り TDD のプロセスを疑似体験できること。言語は、なんだっていい。自分の好きな言語でかけば良い。大事なのは、行ったり来たりするプロセスで、何をどう考え TDD を実践しているか、ということ。困った時はどうするか、行き詰まった時はどうするか。現場は完全な TDD ではないのもの、テストを書いてよかったと思う時はよくあるし、逆になんでテスト書いていなかったんだろうと後悔することもある。そんな時に振り返る原点として、この本を今知れたことは大きい。

印象に残っている箇所

TDD は、設計のひらめきが正しい瞬間に訪れることを保証するものではない。しかし、自信を与えてくれるテストときちんと手入れされたコードは、ひらめきへの備えであり、いざ閃いた時に、それを具現化するための備えでもある。

テストを書くのは、自信をつけるため。逆に言うと、不安な箇所をなくすため。「なぜテストを書くのか」について、あるプロジェクトで手戻りが発生してしまった時の振り返りで感じたことなのだが、その矢先にこの本を読んで出会った言葉。その経験があったが故に、余計身にしみて感じた。

テストを書くと、そしてそのテストがあるべき姿になっているならば、本当に自信がつく。びくびく怯えることなく、リファクタリングできる。自分のためにとっても、今後その箇所を触る将来のチームメンバーにとっても、不安をコードベースからなくすと言う観点は、TDD の本質かも知れない。

慎重な登山者の間では、両手両足の合わせて陸地に接していなければならないと言うルールがあるそうだ。大胆にも2つ同時に動かすと、危険が大幅にますというわけだ。グリーンバーから行える変更は、1つだけというテスト駆動開発の基本形は、この登山者のルールに似ていると言えるかも知れない。

この具体例は非常にしっくりくる。テストがこけているとついつい焦ってしまいがちだが、少し落ち着いてグリーンバーからなぜ離れてしまっているのか、急ぎすぎていないか、振り返る余裕がこれを読んで少しできた、かもしれない。

TODOリストから次に書くテストを選ぶ時には、どうすればよいだろうかーーそこから何かを学ぶことができ、かつ実装に自信が持てるようなテストを選ぼう。

これも1つ目の「自信を持つ」に繋がる話。

独りでプログラミングしている時、コーディング時間のうまい終わらせ方はあるだろうかーー最後に書いていたテストを失敗する状態にして終えよう。

自分はいつも「きりがいいところまで」といってコーディングしてしまいがちなので、この観点は真新しかった。キリがいいところまでかけば気分がいいが、ついつい時間を非効率に過ごしてしまいがちだし、時間をおいてプロジェクトを戻ってきた時、「さて、どこから始めようか」と思うことは、振り返ってみるとたしかに多い。

TDD においてテストは目的を達成するための手段であり、その目的とは、大いなる自信を伴うコードだ。

これも「自信を持つ」に繋がる話。

サンプルレポジトリ

いつもの例に漏れず、今回も手を動かしながら作って見た。 言語は、RubyPython で。他の言語で写経する方法、t_wada さんも本書のどこかで触れていた気がする。

https://github.com/kenju/tdd_ruby

補足

http://t-wada.hatenablog.jp/entry/tddbook

t_wada さんの訳者解説にあたっての工夫や背景、読むだけで熱くなる。ぜひ本書を読んだ方で上のブログ記事を読んだことがない方は、是非読んでほしい。

補足2

そして、t_wada さんの書かれた訳者解説が、また熱い。

その中でも、今回読んだ中で一番印象に残った一言は、これだった:

テストを書いても設計を改善しないのであれば、それはただの回帰テストであり、現状の追認でしかありません。テスト駆動開発における質の向上の手段は、リファクタリングによる継続的でインクリメンタルな設計であり、「単なるテストファースト」と「テスト駆動開発」の違いはそこにあります。

仮に第1版を読んだことがあったとしても、この解説を読むためだけに第2版は買ってもよかった、と思っただろう。