『単体テストの考え方/使い方』
https://gyazo.com/c22de6a64c71fbe9472d1b2ed35aad97
2022/12/28
サンプルコードはC#
章末の「まとめ」がかなりしっかり箇条書きで書かれているので、始めにそこを読むと良さそうmrsekut.icon
全体的に内容は良いんだけど、主張に対して文章量が多すぎ
やっぱ色の付いてないコードは読みづらいなあ
これはしゃあないが
GitHubでコード公開してほしい
第1部: 単体 (unit) テストとは
第1章 なぜ、単体 (unit) テストを行うのか?
A. プロジェクトの成長を持続可能なものにするため
なので、その課題感が刺さりづらい
割と当たり前なことを書いている印象mrsekut.icon
テスト初見の人にとってはかなり良い内容だと思う
どちらかと言うと、テスト書いてない人というよりか、書きすぎている人に刺さる内容か
第2章 単体テストとは何か?
この本はデトロイト学派寄り
この章は、いろいろ整理がなされていて面白いmrsekut.icon*2
第3章 単体テストの構造的解析
1つのtest caseを書く際の指針について
どうやったら読みやすくなるのか
最低限のルールなど
第2部: 単体テストとその価値
第4章 良い単体テストを構成する4本の柱
価値のあるtest caseを認識する
4.1, 4.2がかなり良いmrsekut.icon*2
4本の柱に対する極端な例が書いてるの、イメージがつきやすくて良い
4本の柱のトレードオフの話、言ってることはわかるが実際に書くときにわざわざこれのどれを踏襲しているか、とか考えるものなのだろうか
あー、test pyramidを例にとれば確かにわかりやすいmrsekut.icon
第5章 モックの利用とテストの壊れやすさ
Test Doubleの5分類についての整理
ざっくり2つとして整理してくれるの助かるmrsekut.icon
プロダクションコードの2軸
publicなAPI、privateなAPI
観察可能な振る舞い、実装の詳細
ここから
3つの性質
ドメイン層とアプリケーション・サービス層の関心の分離
依存の向きが一方こう
テストする際にinterfaceを経由する
2つのコミュニケーション
システム内コミュニケーション
実装の詳細
システム間コミュニケーション
観察可能な振る舞いの一部
mockを使って良いのはこちらだけ
第6章 単体テストの3つの手法
単体テストを3つに分類する
C#はOOPやもんねぇmrsekut.icon
FPに関するところは基本的すぎるので読み飛ばした
ここの話、具体的なコードが一切ないけどFP触れたことない人に伝わってるんだろうか
具体的なテストコードを題材にしてリファクタしていく
最初のコードではそもそも単体テストの定義を1つしか満たしていない
元の実装内で、直接fsに依存していた部分をInterfaceに変換することでmockしやすくする
FileContentやFileUpdateといった、eventを表す構造をやり取りするように変換する
これは説明のためで仕方ないのかもしれないが、関数型のアプローチとは発想の順序が逆やなあmrsekut.icon
なぜOOP言語使ってるんスカ、という気持ちになる
第7章 単体テストの価値を高めるリファクタリング
先にまとめを読むmrsekut.icon
コードの複雑さは分岐の数で判断できる
ドメインにおける重要性は、問題領域においての重要度のこと
複雑で重要なものが良いテスト対象
任意のプロダクションコードは以下の4つに分類できる
ドメイン・モデル/アルゴリズム
unit
取るに足らないコード
コントローラ
integration
過度に複雑なコード
↑の2つに分割しよう
コードの広さ、コードの深さ
両方を兼ね備えてはいけない
第3部: 統合 (integration) テスト
第8章 なぜ、統合 (integration) テストを行うのか?
Integration TestとはUnit testではないテストのこと
どのようなプロセス外依存をモックに置き換えるべきか？
プロセス外依存の2つの分類
managed dependency
unmanaged dependency
具体例
先にまとめを読むmrsekut.icon
管理下にある依存を扱う層をすべて経由する検証を行う
確認フェーズでもDBにアクセスする
なるほどmrsekut.icon
サポートログと診断ログ
スタッフが見るか、エンジニアが見るか
第9章 モックのベスト･プラクティス
先にまとめを読むmrsekut.icon
第10章 データベースに対するテスト
DBのテストの事前準備について
Schema定義をGitで管理する
Prismaのmigrationの仕組みとかそれだねmrsekut.icon
開発者ごとに個別のDB instanceを用意する
コンテナなどで用意できれば良い
DB schemaの変更の反映のための2つ方法
状態ベース
DB同士を比較するツールを使う
こっち見たこと無いなmrsekut.icon
移行ベース
Gitで管理するmigration fileを使う
こちらの方がmerge競合への対処が楽
transactionの説明が長え
DBを扱うときの基本的な話だからわざわざテスト本に書くこと無いだろう
DBに対するテストって、具体的に何のテストのこと？
APIのCURDが機能するかとかそういう話？
先にまとめを読むmrsekut.icon
test caseの異なるフェーズで同じDB transactionを使わない
準備フェーズ、実行フェーズ、確認フェーズでそれぞれ別のdb transactionを持つ
どういうこと？
結合テストではtest caseを1つずつ実行する必要がある
テストの後始末に描ける時間を減らす
in memory dbを使わない
書き込みに対するテストが重要
第4部: 単体テストのアンチ・パターン
第11章 単体テストのアンチ・パターン
先にまとめを読むmrsekut.icon
テストのためにprivateなものを公開しない
間接的にテストする
アルゴリズムやロジックの知識をテストに持ってきてはならない
ドメイン知識がテストに漏洩することを避けないといけない