refactoring

Author: tam315

books/refactoring.md

@@ -618,25 +618,28 @@ const main = () => {
 - TDD のメリット
   - すべきことは何かを事前に整理せざるを得ない
   - 実装よりもインターフェースに集中せざるを得ない
-  - コーディングの完了時点が明白
+  - コーディングの完了時点が明白（テストに通過したとき）
 - フィクスチャ
   - テストに必要となるデータやオブジェクトのこと
-- `test`文に与える説明文は、失敗したときにどのテストか識別できる程度に書くとよい。
+- `test`関数に与える説明文の粒度
+  - 失敗したときにどのテストか識別できる程度に書くとよい
   - 説明しすぎは冗長なコメントのようなもの
 - どこに、どれくらいテストを書くべきか
   - 全てのコードにテストを書こうと思わないこと
   - 以下を集中的にテストすること
-    - 一番怪しいと思うところ
+    - 怪しいと思うところ
     - 複雑なところ
     - エラーが起こりそうなところ
-  - 例えばセッターをテストするなどは明らかに無意味
-- fixture をテスト間で共有するな。大変なトラブルのもとになるから。
+  - 無意味なテストをするな（例えば単なるセッターのテスト）
+- fixture をテスト間で共有するな
+  - 大変なトラブルのもとになる
+  - `beforeEach()`を使って分離せよ
 
 ```ts
 // Bad
 describe('', () => {
   const asia = new Province();
-  // many test cases goes here..
+  // many test cases go here..
 });
 
 // Good
@@ -645,37 +648,44 @@ describe('', () => {
   beforeEach('', () => {
     const asia = new Province();
   });
-  // many test cases goes here..
+  // many test cases go here..
 });
 ```
 
-- fixture を共通した方法でセットアップし、テスト文で少し改変したうえで検証するのは、よくあるやり方
-  - いろんな呼び名がついている
+- テストの構成
+  - よくあるのは以下のパターン
+    - 1. fixture を共通した方法でセットアップし
+    - 2. テスト文で少し改変したうえで
+    - 3. 検証する
+  - これには色々な呼び名がついている
     - Set up - Exercise - Verify
     - Given - When - Then
     - Arrange - Act - Assert
   - Tear down というフェーズもあるがこれを使うのはレアケース
     - e.g. 生成にあまりに時間がかかるため、テスト間で共有せざるを得ない fixture を扱っている場合など
 - 境界値の検査
-  - 通常のケースは「ハッピーパス」という
-  - 境界値の例
+  - 当たり前のケースのテストは「ハッピーパス」という
+  - 通常想定されないケースや境界値でのテストも大事。境界値とは：
     - 集合なら空の時
     - 数値なら 0 や負の値の時
     - 文字列なら空文字の時
-- 想定し得ない値を与えたケースでランタイムエラー(e.g. `*** is not a function`など)が出たときの選択肢
+- 通常想定されないケースでランタイムエラー(e.g. `*** is not a function`など)が出たときの選択肢
   - より適切なエラーを返す
   - ログを書いてから親切に値を初期化する
   - 何もしない
     - モジュール間でたくさんのチェックを設けると冗長化して逆にトラブルのもとになることもある
     - 外からくる信頼できない値に対してはちゃんとチェックは必要だけどね
-- アサーションのテストは書かない。アサーション自体がテストだから。
-- ある程度テストを書いたら、あとは作業の進度に合わせてテストを追加してもよい
+- アサーションのテスト
+  - 書かない。アサーション自体がテストだから。
+- リファクタを始めるときにどれくらいテストを書くか
+  - ある程度テストを書く
+  - あとは作業の進度に合わせてテストを追加する
 - バグレポートを受け取ったら、まず、そのバグの存在を明確に示す単体テストを書くことから始めよ
 - カバレージによる分析
   - コードの中のまだテストされていない箇所を突き止めるために使う
   - テスト自体の品質を保証するもの**ではない**
 - テストの品質は品質は主観で決めるのが良い
-  - 誰かが変な変更をしたときにテストは失敗すると確信がもてるか？
+  - 誰かが変な変更をしたときにテストは失敗すると確信がもてるか？という視点が大事
 - テストの書きすぎ
   - テストコード自体の修正に時間がかかり開発が遅れているなら、書き過ぎの兆候かも
   - ただしテスト過多になるケースはほとんどない