日本語のものもあるのですが、そちらは絶版になっているので買うなら中古です。どのようにコードができていくのかがよくわかります。Beck)のテストの書き方がわかるので、自分のやり方を見直すよい機会になります。基本ルールが書いてあります。自動テストに失敗するまで新しいコードを書かない。テストで失敗するまでコードを書いてはいけません。はまる落とし穴に、「テストコードのテストコードを書く必要はないのか」というのがあります。同僚は次のような説明をしてくれました。テストをしていたと思います。テストを書くってことと同じことなんですよ。テストコードそのものの正しさは開発者が担保するようにして進めるんです。わかったようなわからないような説明かもしれませんが、要するにそんなこと言っていたらきりがないからテストコードは開発者のチェックとコードの間に入れる保険なんだと思います。テストコードのバグについてはじゃんじゃん直していいそうです。コードの書き方について重要な方針を書いています。自分の書いたコードのテストは自分で書こうこれ重要ですね。この本をバイブルってことにしておけば、自分で書いたコードのテストは自分で書いてくれって言えますからね。順でやろうと思ったら自分で書くしかないんですけどね。テスト駆動・自動テストのメリット開発現場では往々にして「自動テストなんてやって意味あるのか」「時間がかかるだけじゃないのか」という議論が勃発します。地位の高い人がそういうことを言い出すとどうしようもなくなったりします。自動テストのメリットを再確認しましょう。して4つのことが書かれているのですが、それを仕事上のメリットとして書くと次のようになります。汚いコードの密度が減り、品質保証は受け身の仕事じゃなくて能動的な仕事になる。自分でコードを書くことが品質保証に繋がるので、問い合わせを受けてから手を動かすようなものではなくなります。ドッキリするようなコードに遭遇することが減り、マネージャの見積もり精度が上がる。開発者のみならずマネージャにとっても嬉しいことが起こります。技術的な会話の議題が明確になり、同僚との協力作業の効率が高まる。開発者の能力にもよると思いますが、書籍上ではそういうことが書かれています。汚いコードの密度が減り、新機能の追加されたリリース可能なコードが毎日増えて顧客との関係が向上する。毎日というのは言い過ぎかもしれませんが、バグを見落とすことが少なくなるので新規機能の追加に集中できるようになります。テストドリブンとは関係なさそうな人にもメリットがもたらされるので。どれも理想論に見えますが、テストドリブンの目指すところは上記のメリットです。この本を読んで今以上にテストドリブンに力を入れていこうと思いました。他人への説明も楽にできると思っています。セルをまとめて扱う当サイトの内容、テキスト、画像等の転載・使用を禁止します。