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

テスト駆動開発

これを読んだので感想を書きます

正直、テストが不十分なソフトウェアに対してテストを導入していく仕事をするにあたり読み始めたのですが、よくも悪くもテストとはどうあるべきなのかや何を何テストと呼ぶ、といった説明はあまりなく、ソフトウェア開発における「テスト」についての知識を深めるための書籍ではなかったです

本著にもTDD とは結局の所、分析技法であり、設計技法であり、開発のアクティビティを構造化する技法とあります

テスト駆動開発が個人レベルでの設計・開発におけるテクニックであるということを把握していなかったのでこの点はまず学びでした

I 部、II 部はライブラリを筆者がテスト駆動で作成していく過程を一緒に体験していく形になっています

何を考えてどのようにソースコードに改修を加えていくのか、が丁寧に記載されていてわかりやすかったです

III 部はいろいろなパターンに対する技法がまとまっています

特にリファクタリングについて「メソッドの抽出」、「メソッドのインライン化」、「メソッドの移動」、「メソッドのオブジェクト化」、「パラメータの追加」など個別具体的な状況に対してどのような手順でリファクタリングすると良いかが記載されており大変参考になりました

（この先は完全に個人の見解で、誤りを含んでいると思います）

ソフトウェアエンジニアリングの世界では、実現したい機能があったときに、当然ですがどのような手順で何をしていくかをイメージする（あるいは言語化する）と思います

この手順は人間の思考から出てきたので、人間にとって読みやすいものです

普通の開発では、この手順は当然動作するプログラムではないので、一旦脇において、必要と思われる部品のプログラムを書いていくのだと思います

一方テスト駆動開発ではこの手順をまずテストとして書いて、レッドバーが出ることを確認しているのだと思いました

上に挙げた普通の開発だと、最初にイメージした人間にとって理解しやすいフローは開発中にあまり参照されないので徐々にズレていき、プログラムを書く際に自然な形で実装されていくのだと思います
結果、人間にとっては理解しづらいプログラムができあがってしまいます

テスト駆動開発では人にとって読みやすい手順がテストとして書かれており、テストに対して開発が行われるためそのような事象が発生しづらいのではないかなと思いました

（個人の見解終わり）

15 年前に執筆された本ということで、付録 C にはこの本が世に広まってからテスト駆動開発がどの様に変遷してきたか、が日本語役者の和田卓人さんによってまとめられています

個人的にはここが歴史の教科書的と言うか、いろいろな対立や議論を経て今に至っているのだなという事が分かってとても読み応えがありました

新しく機能を実装するときに、頭の中で考えたフローをまずはテストに書いてみる、ということを実践していこうと思います