ユニットテストを学んだログ
やむ🏔ここ３ヵ月くらいテスト勉強してたのでログを残します。
テストに触れる
テストって何すればいいの？からスタート。
テストが何かを理解すらしていない
検証すれば良いと言われるが
- どこからどこまで検証すればいいのか
- そもそもどういう検証の仕方があるのか
- 効率的に検証する方法はないか
- とりあえず技法を知りたい
これを参考にテスト技法
- 同値クラステスト
- 境界値テスト
- デシジョンテーブルテスト
などの技法を学ぶが、自分的には「これは知りたかったけど、足りないんだよなぁ〜」と感じる
やむ🏔テストの種類を知る
物足りない感があったので追加で購入
- 設計手法としてのテスト（開発者向け）
- 品質担保としてのテスト（テスター向け）
というニュアンスのテストがあると理解する。(上の本は後者)
上の本はどちらかというとテスター向けな本なので、ある程度読んで積読の状態に。点と線と面で考える的な話は面白かった（うろ覚え）
ここまでの2冊は例えるなら筋肉に該当する本だった。
自分が求めてるのは筋肉よりも効率の良い体の動かし方なので積読。
自分が触れているのは自動テストなので自動テストについて調べ直し
余談
テストがないコードはレガシーコードなのだと知りました。
やむ🏔自動テスト
自動テストとはなんぞや？からスタートして下記の本を購入。
とっても初学者向け（プログラミング始めたててくらい）の本だったのでプログラミング学び始めた人は読むと知見を広げられそう。
- RESTの話とか
- JavaScriptを使ったテストとか
- コーディングスタイル・命名についてとか
この本からテストのピラミッドの概念を知る（食物連鎖のピラミッド的な感じでユニットテストが一番下、UIテストが一番上）
重要なのはテスト速度を遅くする事はテストが実行されなくなる危険性を生む為、ピラミッド構造がベストという話なので、ピラミッドを順守する必要はないという点。
モックについても解説が多少ある上に、質問タイプで古典派（デトロイト派）とモック派（ロンドン派）の説明があるが要約しすぎなのと、かなりアッサリ言ってるので本質的な理解が出来なかった。
今読み返してみると重要なことのまとめで良本だけど、知識０の状態から読むと何が重要なのかが全く分かっていないので、吸収率が悪かった。ファスト教養だと応用できない典型例になりました・・・。
やむ🏔良いユニットテストを求めて・・・
メンテナンスしやすいテスト・テストが書きやすいコードとは何かを探し始めました。
そして行き着いた先はxUTP本でした。（高すぎ）
ポインタ集としてこの記事も参考になりました。
ただ原書が英語な上に、サポートページを見た限りだとかなり抽象化された話が多く、自分の中で噛み砕いて落とし込む自信もなければ時間もないです。
そこで自分はPHPUnitを使っていたので色々なスライドを見つつ知見を得ていました・・・。
同時期にTDD本も気になったので読み進めました。
TDD本はテストを開発手法として扱っているので自分が求めていたものに近かったのですが、xUTP本と被っている部分が多く、「源流はxUTP本なんだな」と再認識をしました。
TDD本は実践の部分を飛ばして、第3部のテスト駆動開発のパターンから読み進めただけです。
やむ🏔運命の出会い
「やっぱりxUTP本読まなきゃだめか・・・」と絶望の淵に立たされていた時にO'Reilly Online Learningをサーフィンしていたら興味が引かれる本がありました。
評価も多く、出版年も最近なので自分が求めているにドンピシャなのでは？と思い O'Reilly Online Learningで読み始めました。
余談ですが O'Reilly Online LearningはACM会員で登録するとお得です。
ところがどっこい、自分は英語が読めません。英語アレルギーは無いので抵抗はないのですが、適切な読みができると言われるかとダメです。
なのでDeepLで片っ端から翻訳しました。いちいちコピペして翻訳を見るのはだるいのでChrome拡張で良さそうなのを入れました。
翻訳し続けてると無料枠上限超えるので、その分はしぶしぶ課金しました。
一部翻訳がおかしくなる部分はあれど、その時は原文＋図からの理解で意味を汲み取りました。
この本は自分の中でもユニットテストへの理解を大きく助けてくれた神書くらいのポジションです。
- ユニットテストのゴール
- ユニットテストの派閥
- ユニットテストの命名・構造
- 良いユニットテストの4つの柱(リファクタリング耐性・リグレッションからの保護・保守性・スピード)
- テストピラミッドの話
- モックとスタブの区別とモックの使用場所
- ユニットテストがしやすい実装コードのアーキテクチャ（ヘキサゴナルアーキテクチャ・Functional Architecture）
- Humble Objectパターンと価値のあるテスト
- 統合テストの役割
- モックのベストプラクティス
- DBのテスト
- ユニットテストアンチパターン
ただ読み進めていく上でクリーンアーキテクチャやDDDへの理解が必要になってきたので、そちらの知識も身につけつつ、現在は良いユニットテストを書くために研鑽しています。
ちなみに読んでて一番印象に残った&好きなフレーズは
コードは資産ではなく、負債である。
読んだ（もう一回読んで噛み砕く）
テストしやすさから見ても勉強になります。
読んでいるところ
DDDで有名な松岡さんの書籍を読んでいます。
そのうち読みたい
自分は古典派を推しているのでロンドン派の書き方はしませんがテストへの理解を深めるために読みたいです。
発展
神書を読んでいる途中でFunctional Architectureなるものが出てきたので調べてみても全然情報がないです。
唯一のソースがこれくらい・・・？
なので自分で体験して知見を得るしかねぇ！ということでFunctional Architectureの知見を得るためにジャングルに潜り込みました。
ジャングルは純粋関数型言語であるElmとElm architectureのことです。
純粋関数型言語に触るのは初めてなので、全ての概念が学びになっています。意外と楽しいです。
俺たちのテストはまだまだここからだぜっ！
やむ🏔アウトプット中
神書の焼き回しではありますが、読むのがめんどい！とかそういう人向けに自分の意訳的解釈も多少含めた記事としてアウトプットしています。
余談
ユニットテストを少し学んだ身としてはPHPUnitよりもPestのが取り回しが良く質の良いテストが書きやすいのかなぁと思っています。