https://qiita.com/technoscape/items/4862e4bc62b7c87be5a2
つづき〜
第10章 テストに聞いてみる
第11章 不便になったら消す
・テストが実装変更の障壁になる場合がある
・良いテストは実装を変更しても壊れない
・悪いテストは？
・内部構造に依存している
・使われ方が不自然
・実装の細部まで知りすぎている
第12章 設計とメタファー
良い設計は全員が同じたとえ話でシステムを思い描ける状態である。
メタファーはシステム前提を表現する共通のたとえ・世界観
- なぜメタファーが必要か？
- チームの共通言語になる
- DDDでいうところのユビキタス言語がメタファーを考慮したものになる
- 設計の方向性が揃う
- 命名規則の一貫性を保つ
- チームの共通言語になる
第13章 実装を導くテスト
テストを書くことによってどんな実装かを要求する。
- 必要なクラス
- 必要な責務
- 必要なAPI
テストに書きにくいAPI＝設計の匂い
テストを書くことが設計になる。
ダメなテスト
実装を縛るテスト
assertEquals(1, DB::table('orders')->count());
手順に依存
$order->save();
$order->updateStatus();
$order->notify();
第14章 学習用テストと回帰テスト
テストは学ぶためのノートであり、壊さないための保険である。
-
学習用テスト
- 言語仕様や外部APIの仕様を確認するためのテストを書く
- 外部仕様が変更された場合も検知が可能
-
回帰テスト
- 直したところ以外が壊れていないかを保証するテスト
第15章 テスト任せとコンパイル任せ
機械に保証させられるものは機械に任せろ
テストでしか保証できないものだけをテストしよう
- PHPは動的型付けのため、この場合はどうするのか？
- PHP8.xでは型宣言、union型、readonly、enum、strinc_types、静的解析ツール(PHPStan/Psalm)を組み合わせて実現する
- 最低限やったほうがいいこと
- strict_types
- 型宣言。プリミティブ禁止。ValueObject徹底する
- PHPStan (Level7〜8)
第16章 将来の読み手を考えたテスト
テストは動作確認の道具だけではなく、未来の開発者への設計ドキュメント
良いテストとは
- 意図を語る
- 余計な情報を書かない
- 実装を語らない
悪いテスト
- Foo,,bar,hoge,fugaなど意味不明な単語を使う
- 何がしたいかわからない
- 業務文脈がゼロ
public function testFoo()
{
$a = new A();
$a->setX(3);
$result = $a->bar(4);
$this->assertEquals(7, $result);
}
良いテスト
- 何を検証しているか読める
- ドメイン用語で語られている
- 実装ではなく「意味」にフォーカス
public function test_calcurateDiscountedTotal()
{
$order = Order::new()
->withSubtotal(10000)
->withDiscountRate(0.1);
$total = $order->calcTotal();
$this->assertEquals(9000, $total);
}
テスト名だけで仕様が理解できる
処理名ではなく業務命題
第17章 多国通貨の全体ふりかえり
あらためて、1部全体の振り返り
TDDのリズム
1.小さく書く（Red）
2.とにかく通す(Green)
3.設計を整える(Refactor)
設計ポイント
* 単純さを最大優先
* 重複は容赦無く消す
* テストが設計を引き出す
* 意図が先、構造は後
* TDDは未来を予測しない設計手法である