『単体テストの考え方/使い方』
https://m.media-amazon.com/images/I/81KjnYBFY9L._SY522_.jpg https://www.amazon.co.jp/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9-%E4%BD%BF%E3%81%84%E6%96%B9-Vladimir-Khorikov-ebook/dp/B0BLTG8Z9K/ref=sr_1_1?crid=SF23K8U591XU&dib=eyJ2IjoiMSJ9.V4C7J78RCbKUoo8Fw4T4ttudZNv88Uo1SwalHFiQleydWiejRvZ4FMKaWC2_nMAUqmYNt9oXib7xgPbVG5SmqOKU5Ot29pteVCPxQJyII-kSkK2yptlxa-S3eCtNLc5r5g9LbdVtV7KuEmkxgVVw_3i8B2HBfCVqtSVH13LOYyUYXh9TY4_I057-PSOHp-1i9xzDmxoWOSpBywjTogCXvvDIwDCWbxdC1DUjNK_mQP6jB8O84tczrMnz4QZFH80LR5h-NiiAW2cJ--5lnLoj5I9cC3WyPY7dWitTgN9uyz8.TbuQa1SLA6jkWdgcgOgPgzJURxQH14hU8e4YWNjyR90&dib_tag=se&keywords=%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9%2F%E4%BD%BF%E3%81%84%E6%96%B9&qid=1723462278&sprefix=%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%2Caps%2C166&sr=8-1
ISBN:B0BLTG8Z9K
古典学派とロンドン学派の違いを詳しく紹介しつつ、古典学派ベースで進行していた。
理論的に話が進むので読みやすかった。
バックエンドよりの話が多いが、フロントにも適用できそうな範囲ではありそうだった。
テストを書けばいいってものじゃないことが分かった。
良い単体テスト、結合テストに絞って書くことが大事。
このようになコードが（特に英語を母国語とする人たちにとって）読みやすいコードなのです。
英文法に沿ったAssertで書くと読みやすい話での一文。
翻訳本らしいカッコ書きで好き
第一部
テストコードも保守対象なので、プロダクトコード同様に負債になる
ドメインモデルのテストを重視する
古典学派の単体テストはロンドン学派の視点から見ると、ほとんど結合テストに当たる
collaboratorのオブジェクトをそのまま使い、モックしていないため
古典学派でもテスト・ダブルを使う
ロンドン学派は、共有依存と可変依存をテスト・ダブルにする
古典学派は、共有依存だけテスト・ダブルにする
単体テストは、1クラスやメソッド単位ではなく、振る舞いをテストする
テストメソッドにテスト対象のメソッド名をつけない
非開発者でも分かるような名前にする
日本語でもいいかも
パラメータ化テストは読みやすさとトレードオフ
正常系と異常系でテストを分けるぐらいが良い
第二部
手順を検証するテストは質の悪いテスト
リファクタリングへの耐性が低い
結果を検証するテストは質の良いテスト
howではなくwhatを検証する
単体テストは、保守のしやすさとリファクタリングへの耐性を最大限にする
対抗に対する保護と迅速なフィードバックの間でバランス調整する
保守のしやすさ以外の3つは互いに排反する
テストケースを作成するときは、ブラックボックステスト
テストケースを分析するときは、ホワイトボックステスト
出力ベース・テスト、状態ベース・テスト、コミュニケーション・ベース・テスト
出力ベースが一番関数型プログラミング的でテストに向いている
Humble Object (質素なオブジェクト)で複雑なコードを抽出するとテストできる
要はコントローラ
ここにビジネスロジックを持ち込みすぎないように注意する
確認後実行パターン
第三部
単体テストでは、異常ケースをたくさんテストする
統合テストでは、ハッピー・パスと単体テストでは扱えない異常ケースをテストする
結合テストで実際のデータベースをデプロイできない場合でも、モックしない
モックしてもリファクタリングへの保護が失われたテストコードになってしまう
仕方ないので単体テストケースを頑張る
プロセス外依存にだけインターフェースを使う
モックのためにインターフェースを作らないこと
複数の実装の抽象化のためにインターフェースを使うのはOK
循環参照回避のためにインターフェースを使わない
むしろ複雑性が上がってしまう
そもそもの循環参照を解決すること
ログは外から見えるサポートログはテストする
診断ログはテストしない。そもそも診断ログはできるだけ無い方が良い
プロダクトコードを信頼しないコードを書く。検証するように
システム境界にモックを使う。スパイにするとテストコードの再利用性が上がってより良い
書き込みのテストが重要。読み込みのテストは複雑なものや特別重要なものだけにする。
リポジトリ層は保守コストが高いため、直接テストしない。
統合テストで間接的に検証する
第四部
プライベートメソッドをテストのために公開しない
間接的にテストすること
テストしたい一部を抽象化して、別のクラスに抽出すること
リフレクションで無理やり開けたりもしないこと
ORマッパーから呼び出しがあるなど、外から観察可能なメソッドならテストして良い
プライベートな状態も、テストのために公開しない
クラスの一部だけをモックしたくなったら、SSoTではない警告かも