- Amazon.co.jp ・本 (344ページ)
- / ISBN・EAN: 9784274217883
作品紹介・あらすじ
テスト駆動開発の原点が新訳で蘇る
本書は、自分たちのコードに自信を持って開発を続けたいプログラマ、チームリーダー向けに、テスト駆動開発(TDD)の実践方法を解説した“Test-Driven Development By Example”の日本語版です。テスト駆動開発の考案者であるKent Beck自身によって書かれた原典を、日本におけるテスト駆動開発の第一人者である和田卓人氏が訳しました。
テスト駆動開発とは単にテスト自動化を行うことではなく、ユニットテストとリファクタリングを両輪とした小さいサイクルを回すことで不確実性を制御し、不断の設計進化を可能にする手法であることを、実例を通して学ぶことができます。
感想・レビュー・書評
-
これを読んで、テストを先に作る正しさを、理解。
日本のソフトウェア開発よ、今までの習慣を変えよう。詳細をみるコメント0件をすべて表示 -
テスト駆動開発の先駆けとも言える本の再翻訳本。
自分のプログラミングでツールによる単体テストが身に付いていないので、書店で見かけてよい機会なので購入した。
三部構成で、第1部は為替レートのプログラミングを事例にテスト駆動開発を実践し洗練していく過程を示している。ソフトのコードとテストのコードが最初のシンプルなものからどんどんブラッシュアップするテスト駆動開発の流れがわかる。
第2部は改めてxUnitを使ってテスト駆動開発のフレームワークを説明している。第3部はテスト駆動開発のノウハウ集となっている。
丁寧に実例を追いかけていくことでプロセスを目にすることができ、また理論もきちんと説明しているので応用もしやすく実用な本と言える。 -
「自分ひとりでできる技術」である TDD を解説する本。
付録Cには2002年から2017年までの周辺事情の解説(訳者による書き下ろし)がある。書籍全体の最後をふりかえりで締めるところが、本文の各章でも最後をふりかえりで締める構造と調和していて素敵だなと思った。
比較的コードサンプルが多く登場する。打ち消し線や太字などでわかりやすくなるよう工夫されているが、本文と地続きなのが残念だった。色付けや囲みになっているとよかった。 -
テスト駆動開発というワードを見聞きして数年、ようやく本書を読むに至る。本書を読んで、自分は「TDDは最初にテストを書く、テストファースト」という誤解をしていたのだと気付く。
テストコードを書くと同時に、プロダクトコードのリファクタリングも行うことで、プロダクトの品質を高めていける。開発や設計を継続的に改善していくために、レッド・グリーンの過程をまず経る必要があるのだ。という理解に至った。
他の方の感想にも書かれているが、まず付録Cから読み進めることをオススメしたい。 -
TDDを具体的に理解し行動に移したい、
という人にはかなり有効な本だと思う。
今はVUCAな時代。
そんな時代はアジャイルな開発手法が適している。
アジャイル開発が効果を出すにはDevOps環境が必要。
そこに不可欠な要素が「TDD」だと思っている。
そんなことはわかっていても、
「具体的にどんなアクションプランを描き、
今日から何をすればよいのか?」
という落とし込みが難しく、私はここで躓いていた。
本書はそれを大いに助けてくれる。
「今日からあなたはこれをこうやって試し始めればいいんだ」
ということを教えてくれる。
豊富なサンプルコードを交え、
度が過ぎると思えるほどの小さなステップを踏みながら。
若干くどい印象は否めないが、
それが本書の特徴であり良さでもあるのだろう。 -
現代のソフトウェア開発をするのであれば、絶対に読んでおくべき一冊
-
本編の内容としてはもはや古典になってきたが、付録 C が秀逸。テストとはなんなのか、なんのためにするのかを考えさせられる。
-
テスト駆動開発
プログラマーのKent Beck氏の著書です。
テスト駆動開発(Test-Driven-Development:TDD)の実践的なやり方を解説した本になります。
【本書で学べること・考えること】
- TDDのサイクル(レッド、グリーン、リファクター)
- TDDの進め方
- テストフレームワークの作成方法
- TDDのパターン
- リファクタリング
- TDDの意義
読んでみての感想です。
XPなどで提唱されるTDDを実際の業務で取り入れようと思い、いざ始めてみると実際のやり方が良くわからないということに気がつきました。
そこで、定評のあるこの本を手に取り、実際のプラクティスについて学びました。
実際のTDDは、非常に小さなステップでサイクルを回していることに驚きました。
また、進めていくうちにテストの変更も行っていることがわかり、試行錯誤しながら進めて良いことも理解できました。
もっと、きっちりしたテストを書かないといけないと思っていたので、ハードルが下がりました。
脱線しそうな時はTODOリストに書き込むのも良いアイデアです。
これらを実際に行うとテストのカバーレッジも増えますし、コードもきれい、テストしやすいコードになるだけでなく、プログラムを作成していく中で、自然とコミットも良い粒度に収まるようになります。
さっそく、実際の業務でも実践してみましたが、コードの動作に自信が持てるし良い感触を得ています。
第二章のテストフレームワークについては、現状、各言語とも充実しているので必須ではないですが、動きを理解しておくことは必要かなと思います。
第三章のパターン化については、使用する言語によっても変わってくると思いますので、参考になる部分を取り入れていこうといった感じです。
巻末の翻訳者である和田さんの記事は、TDDの現状を補足していてくれて、是非、一読したい内容です。
個人的には、テスト駆動開発をやりたいと思ったら、第一章を読むべきと思います。
参考になりました。 -
テストファースト大事だが
途中で書き替えて品質担保できるかは疑問 -
The テスト駆動開発
凄く良いんだが、「動作するきれいなコード」という言葉は経験者にしか刺さらず普及には向かない。
Clean AgileでのTDDの必要性の説明が1番しっくりくる。