will and way

ただの自分用メモを人に伝える形式で書くことでわかりやすくまとめてるはずのブログ

レガシーコード改善ガイド11章〜15章

11.変更をする必要がありますがどのメソッドをテストすればよいでしょうか。
目的:変更の際に影響範囲を調べるテクニックを学ぶ

影響スケッチ
→変更する変数と変更に影響が出るメソッドを楕円でつないだもの。
→エンドポイントをテストすれば良い。

とりあえず、更新系のメソッドを探し出し、順序的にどのように更新されるのかを確認しておく。


調査方法
1.変更場所を決める。
2.変更をきめる
3.変更によって影響するメソッドを探す
4.3で見つけたメソッドをテストして、影響をしらべる。
5.スーパークラス、サブクラスへの影響を調べる
6.特定したメソッドでグローバル変数やstaticデータの更新をしているか調べる

※戻り値を持つメソッドに着目する。(処理した結果を返すので影響が出る場所である可能性が高い。)

ファイアウォール
変数の可視性をprivateにすることで、影響範囲を減らす。


12. 1箇所に沢山の変更が必要ですが、関係するすべてのクラスの依存関係を排除すべきでしょうか?
結論:上位レベルのテストはその内部で利用しているメソッド達のテストをしよう。
ただし、単体テストの代替ではない。

割り込み点
変更による影響を検出できるポイント→ここをテストする
割り込み点は複数あるが、変更に近いところを選択すると良い。
→テストハーネスの準備も楽になるし、書いたテストが何をテストしたいのかもわかりやすい。

絞り込み点
そのメソッドを通じて他のメソッドやクラス群の振る舞いをテストできるポイント
影響スケッチをしよう。

落とし穴
→テストを書くのが難しかったり、テストに時間がかかってしまったりする。
→テストが大きすぎる場合は擬装オブジェクトを利用すればテストできる。


13. 変更する必要がありますがどんなテストを書けばよいのかわかりません

仕様化テスト
現状、実際にどのように動作しているか、確認する→テストを書く。
1.対象コードをテストハーネスから呼び出す
2.失敗するテストを書く
3.失敗から動作を確認する(返り値)
4.テストを修正する
5.繰り返す

はじめに正常系のテストを1つかく。
1、対象メソッドを決める
2、引数にnullを渡してみる
3、newしたオブジェクトを渡してみる
newしたオブジェクトに必要なプロパティをセットする

2、

クラスの仕様を特定する
1.検出用変数を仕込む
2.責務が確認できたら失敗するケースを考える
3.入力してみる
4.失敗の不変条件を発見する

狙いを定めたテスト
分岐にかかわる変更をした場合には分岐を通るテストをする必要がある
その時はデバッガを使ってその部分を通るか?を確認する必要がある。

リファクタリングの際に型を間違えてもうまく行ってしまうケースが有るので、
そこはデバッガで確認しよう。


14. ライブラリへの依存で身動きが取れません
ライブラリに依存しすぎている場合はラッパーを作るくらいしかできない。


15. 私のアプリケーションはAPI呼び出しだらけです
API呼び出しが多いコードは保守が難しい
→ライブラリに構造が依存してしまうため、構造変更が難しくなること
→ライブラリの変更ができないこと。

14の問題に近い。
手法
APIをラップ
API/ライブラリそっくりのインタフェースを用意しシグネチャの維持を行う。本番クラスは委譲するのみ。
作業量が多いが自分たちが書いたロジックへの修正が少ない
利用シーン
→簡単なAPI
→ライブラリ依存を無くしたい
API依存によるテストが出来ない

・責務を元に抽出する
責務単位でメソッドに切り出す。切り出したクラスに対しインタフェースの抽出を行えば依存性も軽く、テストしやすくなる。
リスクはあるが、責務単位で切り離されているため再利用しやすくなる。
利用シーン
APIが複雑
→ツールが有る、手動での抽出を安全に行う自信がある