テストのサイクル
- 小さいテストを一つ書く
- 全てのテストを実行し、一つ失敗することを確認する
- 小さい変更を行う
- 再びテストを実行し、全て成功することを確認する
- リファクタリングを行い、重複を除去する
依存性と重複
ベンダー固有のSQL実装に依存したコードをあちこちに書いていると、DBベンダーの変更で多くの書き換えが発生する
オブジェクトを使えば抽象化によってロジックの重複を綺麗に取り除ける
重複を除去することによって、たった一つの変更だけで次のテストを通せるようになる確率を最大化させる
テスト駆動はアーキテクチャ駆動とは正反対の手法
Value Object パターン
別名参照（aliasing）を気にする必要がなくなることがメリット
equalsメソッドを実装しなければならない
三角測量
責務
インターフェースとして定義した方が考えることが少なくて済む
Expressionを実装する際の言葉
あとあとでクラスのメソッドの宣言をインターフェースに引き上げるときに、キャストやクラスのチェックといったコードを排除できる
メタファーの重要性
銀行、式
テスト間の依存関係
テスト間には絶対に依存関係を作ってはならない
オブジェクト指向プログラミングは３つの階層構造で整理できるようになっている
- モジュール（パッケージ）
- クラス
- メソッド
第32章 TDDを身につける
不安が退屈に変わるまでテストを書く
テストしやすいコードは適切に分割されたコード
前準備コードの重複が多い場合、密に関連し合うオブジェクトが多いことを意味する
読んだ感想
金融システムへのある変更（多通貨対応）に対して、大きなTODOを作成する。そのTODOに至るまでのTODOを分割して作成する。それを実現するためのテストコードを書く。まずはテストを実施するために、失敗（レッドバー）を前提とした実装をする。無理矢理にでもテストが成功（グリーンバー）するようにする。全体の整合性を取るために少しずつ実装を進める。大きく実装したかと思えば微調整を加え、再検討する。出てきた問題に対してまたTODOを追加する。
どうやら、TDDというのは、技術ではなく、設計思想のことのようだ
正確にいうとAIコーディングに活用するとしたら、大きな目的を細かいTODOに分割し、適宜全体の設計にフィードバックをしながら開発を進めていく手法。
当初は最初に重要なテストを列挙して、全てチェックを通れば品質が確保できるんでしょ？と思っていたが、読み進めていくと完全に違うことがわかる
細かいステップでコードの修正と解説がおこなれているので、ケントベックのライブコーディングを見ているかのよう。コードを写経しながら進めればペアプロをしている感覚が得られるかもしれない。
大事なことは大体めんどくさい
18章からは第二部、xUnit。これはJUnitのようなテストツール自体を作成することによって、テスト駆動開発を理解するという内容。
AIを知らないことをやってくれるツールとして捉えることは面倒なことの先延ばしになる。自分の力の増幅機、また自分の足りないところを気づかせてくれるツールとして捉えたい
あまり難しいことは考えたくないが、考えるのをやめて「もうこれでいいじゃん」と大多数の人が思うようになった時がシンギュラリティが起こる時だと思す。
ウォーターフォール開発との親和性はあるか？
- 設計と実装が逆転しているような印象を受ける
- 「設計手法としてのTDD」ではなく「仕様検証ツールとしてのテスト先行」と捉えると良い
- 事前に作成するプログラムイメージが生まれるため仕様齟齬に気づく機会が早めに訪れる
疑問
副作用、という言葉が指す範囲がよくわからない。単純にオブジェクトの変化についてなのか、もっと抽象化・一般化できることを指しているのか
Leave a Reply