2024.01.15 2025.02.15

【TDDは死んだ】テスト駆動開発【要約・感想・まとめ】

ちゅけ

記事内に商品プロモーションを含む場合があります

本記事の内容

書籍情報
- 著者について
書評
感想・まとめ
こんな人におすすめ！
総評

書籍情報

テスト駆動開発 [ Kent Beck ]

created by Rinker

¥3,080 (2025/04/02 10:05:09時点楽天市場調べ-詳細)

メルカリでの検索結果はこちら

書名：テスト駆動開発

著者名：ケント・ベック(Kent Beck)(著者)、和田　卓人(翻訳者)

出版社：オーム社

著者について

参考

ケント・ベック(Kent Beck)(著者)

エクストリーム・プログラミング (XP) の考案者でアジャイルマニフェスト (Agile Manifesto) の起草者の一人。彼はデザインパターン、テスト駆動開発、Smalltalkに関する本を書いた。ベックはウォード・カニンガムと一緒にCRCカードを普及させた。SmalltalkのユニットテストのフレームワークであるSUnitを開発した。さらにエーリヒ・ガンマと共同でJavaのユニットテストのフレームワークJUnitを開発した。ケント・ベックはオレゴン大学のコンピュータサイエンスの修士号を取得している。

引用元：wikipedia

和田卓人 (翻訳)

タワーズ・クエスト株式会社取締役社長、Seasar プロジェクトコミッター。テスト駆動開発を雑誌連載記事、動画講座、カンファレンスでの講演や講義などを通して国内に紹介した。また、テスト駆動開発に関連する用語として、デベロッパーテスティングという概念を国内に紹介している。

本書において重要な知恵を与えてくれる付録Cを書きおろしている。

引用元：wikipedia

書評

どんな本？

TDD(Test Driven Development) テスト駆動開発の原点ともいえる本。

XPの考案者でもある著者がソフトウェア開発の領域に置けるテスト駆動開発とはなにか、どのように実践すればいいのかを実際にコードを書くことで解説している。

また翻訳者が記載した付録CではTDDの成り立ちと現在の立ち位置についても説明している。

読んだきっかけ

ちゅけ

テスト駆動開発についてきちんと学びたいと思ったことがきっかけです!

要約

テスト駆動開発の目的は「動作するきれいなコード」をつくること。そのためにはシンプルなルール2つを守ればいい。一つは「自動化されたテストが失敗したときだけ、新しいコードを書く」もう一つは「重複を除去する」。言い換えればユニットテストとリファクタリングの両輪とした小さいサイクルを回すことで不断の設計進化をすること。
テスト駆動開発ではテストコード→本体コード→リファクタリングの順で機能を開発していく。必ずこの順番を守らなければいけない。テストファーストが本体の実装をテストしやすい粒度にとどめられ実装が独立性を保ちやすくなるからである。
「TDDは死んだ。」この言葉はRuby On Railsの作者「DHH」による言葉で、絶対にTDDで開発しなければいけないという狂信的な考えは忌むべきものという意味である。元ネタ記事の翻訳はこちら
TDDとテストファーストの違いはテストをした後コードの修正でとどめるだけなく設計の見直しを行うことで質を高めることである。

良かった点・悪かった点

メリット

TDDの具体的な方法をコードを示しながら説明されているため実践できる
なぜTDDが有用なのかがわかる
和田さんが書き下ろした付録C「テスト駆動開発の現在」が現在のTDDの実態を解説してくれている。

デメリット

テスト駆動開発の手法を紹介している本なので概念だけをしれればいいという人には過剰
コーディングをしたことがない人には実践方法の理解は難しいかも

感想・まとめ

本書ではTDDとはなにかどのように実践すればいいのかを学びました。

本書でまず注目すべきは何と付録Cです。数々のレビュー記事で絶賛で中には「付録Cは付録の域を超えている」といった意見もありました(笑)。この章を先に読んでから本文に入ることでよりスムーズにTDDについて理解することができます。

付録Cは翻訳者の和田さんが書き下ろしておりタイトルは「テスト駆動開発の現在」です。TDDの現在までの変遷をこの本が出版された2017年まで解説しています。概略としては現代のTDDは教条主義化（～しなければいけないという強迫的な教え）と意味の希薄化により過小評価されているとのこと。またTDDの本質は結果（生成されたテストとコード）ではなくプロセス（思考プロセスとリファクタリング）にこそあると記載されています。TDDの衰退によりテストを自動化するのが当たり前という風潮は非常に大きな一歩となったとも記載されていました。

私自身も本書を読むまではTDD=テストファーストであり、バグを生み出さないことが目的だと思い込んでいました。しかし本書を読んで本来の意味とは違っていたのだと理解することができました。TDDの本質とはプログラマが思考しながら、リファクタリングしながらコードを書くことにより継続的に設計を見直すことでより質の高いコードを生み出す手法だと考えました。

本書は決してTDDの使用を強いるものではなくあくまでこのような開発手法があるということを知識として蓄え場合に応じて適切に使えるようにしてほしいと記載されていました。

私としてはプロジェクトごとにやり方があるのでそれに従うのが前提と考えてはいますがTDDで開発している現場では本書の内容を思い返し実践することで対応することができると考えています。