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

本書の構成

• 第1部: 他国通貨
  • 通貨同士を変換するコードを通して、テスト駆動開発を体験する
• 第2部: xUnit
  • JUnitなどのテスティングフレームワークを使用してみる
• 第3部: テスト駆動開発のパターン
  • テスト駆動開発に関する実践的なテクニック、知識など

感想

• タイトルからは分かりづらい部分だが、少なくとも他国通貨の章はJavaで全て書かれており、Java使わない人が読んでも意味不明な箇所が多いと思う

参考になった箇所

斜体部分 は引用箇所

• 目指すのは、動作するきれいなコード
  • 最初に「動作する」に取り組み、その後で「きれいな」に取り組む
• TDDを実践すると開発は遅くなるということは作者が認めている
  • TDDをやっていると、テストコードとプロダクトコードの行数は、同じくらいになる。つまりこれまでの2倍コードを書けるようになるか、半分のコード量で同じだけの機能を書けるようになるかしないと、TDDのメリットを得られないということだ。
• テストをきれいに機能させる3つのアプローチ。仮実装、三角測量、明白な実装
  • 仮実装: コードでまずベタ書きの値を使い、実装を進めるに従って、置き換えていく
  • 三角測量: 2つの実例から、汎用性の高い解を導く
    • 特にこの項目が、自分の経験からもすごく腑に落ちている。もやもやしたアイデアが言語化された感覚があった。
  • 明白な実装: すぐに頭の中の実装をコードに落とす
• テストとコードの間の重複除去が、設計を駆動する
• コードを書く際にストレスに悩まされないコツは、どこに行くべきかがわかるまでは、一歩も踏み出さないことだ
  • この一文は、ある程度やることが決まっている業務上のコーディングでは有効だと思った。
    • 逆に、自分で使うだけのツールなど、見切り発車で進めて場合には、手を動かしてもいいように思う。どうでしょうか
• アサートファースト
  • いつアサーションをかくべきだろうか――最初に書こう
  • 何から書くか迷ったときは、「アサートから書く」ということを忘れているとき
• 休憩
  • 休憩についても書かれているのが本書で面白いと思ったところだった。でも、最もなことを言っていると思う
  • 疲れたり手詰まりになったりしたときはどうすればいいだろうか――休憩を取ろう。
• ロジック1行毎にテストを書くべきか、数百行まとめてテストを書くべきか
  • 答えは「どちらもできるようになろう」だ。
  • 最初は細かく書くべきだが、経験を積めば後者も可能
• テストしなくても良いもの
  • 不安が退屈になるまでテストされたものがそれに該当する
• 良いテストとは
  • 逆説的に悪いテストを上げている
    • 前準備に要するコードが長い
    • 前準備コードの重複
    • テスト実行時間が長い
• どのテストを消すべきか
  • 2つの判断基準 -> 自信とコミュニケーション
  • コミュニケーションとは: 読み手が異なるテストと認識するなら消さないこと
• 途中からTDDに切り替えるには
  • この項目を語るには余白が狭すぎるとして多くは語っていないが、「変更予定がない箇所は触らない」ことと、「テストとリファクタリングの間のデッドロックを解消する」事が挙げられている