クラスとテストの相互関連

『単体テストの考え方/使い方』を読んでる。

公開インターフェイスを上手に設計しているならば、テストもしやすいはず。

テストを書いていて、書きづらいなとか、何か変な感じがするなぁと思ったら、テスト対象のクラスやそのインターフェイスに改善点があると考えてみると良い。

単一の公開インターフェイスをテストするだけじゃ足りないなぁと思うなら、カプセル化に改善点があると考えてみると良い。

あくまで単体テストの話。

公開インターフェイスを変えないといけないとか、モデリングをやり直すとかになってくると、E2Eテストでしか挙動を保証できなくなってくる。E2Eテストは取りうるパターンを網羅的に書くことはコストになるのであまりないと考えると、それらの修正は挙動の保証を目視で行うことになり、コストが高くついてしまう。

だからまずクラスを追加するときはちゃんと設計するべきだし、ちゃんとレビューするべき。気をつけねば...

下に行くにつれてコストが高くなってしまう気がしている。そのため、初動で慎重にやりたいところ。

クラスのAPIを変えないリファクタリング

クラスのAPIを変えるリファクタリング（メソッドシグネチャを変えるようなリファクタリング）

他のクラスも含めてクラスをモデリングし直すリファクタ