[読書レビュー] テスト駆動開発

レビュー

★★★☆

この本を読む前まで、テスト駆動開発って、テストコードを最初に書くだけだと思っていたけど、 実際のコードを書かないのに、どうやってテストコードを書くんだろう？と疑問でした。 でも、実際のコードを書く前の設計と、コードの構成を安定化させるために、テストコードを書くという概念が学習できました。 そして、斬新だったのは、実際に書いたコードは、本番コードを作っていく過程で、どんどん消していくというフローです。 テストが全部消し込まれたら、コーディング作業が完了するという事です。 でも、このTDD（テスト駆動開発）を仕事で実行しようとすると、1人での作業であれば、問題なさそうですが、 開発チームなどの組織開発の場合は、ルール設定と、メンバーのTDD学習が必須になるし、 そもそも、TDDは、否定はも数多くいるらしいので、意識統一するのは、なかなか骨の折れる作業になりそうな気もしますね。 個人的には、TDDは悪くない開発手法なので、消し込んでいくテストコードをそのまま、CICD的な、継続テストできるコードに移行できるようなフローに持っていけると、 開発全体から、運用フェイズにおける効率化が良い感じになると思ったんですよね。 でも、残念ながら、この手の翻訳本は、正直日本人の読み物としてはかなりもどかしい言い回しの羅列になっているので、正直読みにくいとは思う。 拡大解釈しながら、書いてあることを、ガイジンが言っているとして、日本人ならこう考える・・・みたいな思考で読み進めないと、まるで意味のわからない文章のようにも思えてしまいます。 決して翻訳者が悪いと言っているわけではなく、本来翻訳は、解釈を変えてはいけないというグランドルールがあるので、はっきり言って英語現代を読むぐらいの思考がいいのかもしれないね。

この書籍の学習ポイント

プログラミングとは・・・

井戸からバケツで水をくみ上げるようなものだと想像してみよう。もしバケツが小さいなら、クランクを回して引き上げるにはただの滑車で十分だ。大きいバケツが水でいっぱいなら、引き上げきる前に疲れてしまう。クランクをひと回しするごとに休むためのラチェット機構が必要になってくる。バケツが重くなればなるほど、ラチェットの歯車を細かくしなければならない。 ＫｅｎｔＢｅｃｋ. テスト駆動開発 (p. 9). (Function). Kindle Edition.

WXとTDDの違い

エクストリーム・プログラムと、テスト駆動開発の違いについて、 エクストリーム・プログラムとは、先に進むために取り組むべき事の開発。 テスト駆動開発とは、プログラム中の設計判断とフィードバックの間にあるギャップを認識し、コントロールする手法。 この２つは、まるで違うと同時に、組み合わせた手法ができるという事がわかる。

テストの書き方（概念）

用途に合った完璧なインターフェイスを想像するのがポイントだが、 理想的なAPIから書き始めて、逆向きに作業していく方が王道。

TODOリスト

TODOリストを作って、それにそってテストを書く方法が掲載されている。 この時、TODOリストは、文章で書いてあり、それ自体がテスト品質にもつながる。 実際のテストは、ツールを使っても良いし、今では多くのプログラム言語で、UNITなどの機能が実装されているので、それを利用してもいい。

デザインパターン

オブジェクトの処理をまとめて特定の場所で使う事は、内側で生成された諸問題の予測や解決ができる最善の方法。 リファクタリングを設計行為として捉えていないのは、NG。 いくつかのパターン要約が書籍に書かれているので、ある程度の参考にはなる。

リファクタリング

一般的なリファクタリングでは、どのような事情であれ、プログラムの意味を変えることは許されない。 しかし、TDDにおけるリファクタリングでは、気にかけなければならないものは、すでに通っているテスト、ということになる。 つまり、TDDでは、ベタ書きの値を、変数に置き換える変更であっても、胸を張ってリファクタリングと呼べる。

TDDのパラドックス

将来のことを考えずにコードを書く事が、将来そのコードが状況に適応する可能性を広げる。 開放閉鎖原則（Open / Close Principle オブジェクトは利用に対して開かれていて、修正に対して閉じられるべきである） は、徐々に満たされる。 正確には、バリエーションの発生によって満たされるようになる。 テスト駆動開発によって開発されたフレームワークは、発生したバリエーションを正確に表現できる。

著者談

どんなにクールなツールがあっても、プログラミングはいまだに難しい。 私はコードを書いている時に、ボールを同時にいくつも空中に放り投げているような感覚を覚えることがある。 集中が途切れると、全てをとりこぼしてしまう。 テスト駆動開発はそのような感覚を減らし、高速な動きの中に落ち着きをもたらしてくれる。

あとがき

イケてるエンジニアから、「TDD」という言葉を聞くのだが、実際に現場で使っているというのを見た事がなかった。 なので、書籍を読んで、自分だけでもこうした手法を身につけておこうと思ったのだが、 なかなかの宗教チックな内容に少しだけドン引きした場面も、読書をしながらあったのも事実なんですよ。 ただ、テストを書くのは、おまけ的な要素で考えていた開発手法が、 テスト必須の思考に切り替えてくれたのは、自分の今後の開発人生において、非常にプラスに働いたと思います。 実際に、仕事におけるコーディングも、「こんなテストを書いておくと、何らかの時に検知しやすい」と考えながらコーディングするようになったし、 実際に、自動テストをある程度書きながら開発をするスタイルも身についてきた。 まだまだ、TDD自体が完璧なスタイルではないと、書籍にも書いてあるけど、思考しながら、自分なりのTDDを作っていくのも悪くないかもしれないと思った。