テスト駆動開発輪読会 Vol.5第25〜28章2020/08/11 @masyus_work
View Slide
1~24章まで学んできたテスト駆動開発のTipsを紹介1. テスト(名詞)2. 独立したテスト3. TODOリスト4. テストファースト5. アサートファースト6. テストデータ7. 明示的なデータ第25章テスト駆動開発のパターン
第25章 テスト駆動開発のパターン1. テスト(名詞)- テスト(動詞) = 評価する- 手動のニュアンス- テスト(名詞) = 合格か不合格かを判定する手順- ★自動のニュアンス2. 独立したテスト- テスト同士は独立にしておかないと、1つのFailで後続のテストも連鎖的にFailしてしまうから良くないよね
第25章 テスト駆動開発のパターン3. TODOリスト- やるべきことを粗い粒度で書き出す- 「すぐやる」「あとで」「やる必要なし」に仕分け- テストケースは後回しにしない4. テストファースト- 実装後にテストを書くことってあまりない- テストを先に書くと、設計について考えたりスコープ制御するようになるので、テストを書くこと自体のストレスを減らせる上に、もっとテストを書くようになる
第25章 テスト駆動開発のパターン5. アサートファースト- 実装した機能がどんな結果を返すかを評価するところから書く- 正しい結果とは何か・それをどう検証するかを設計に起こしやすくなる6. テストデータ- 2 (第1引数) - 3 (第2引数) = -1- 3 (第1引数) -2 (第2引数) = 1- 本番に近いデータを準備する- 並列試験中やリファクタリング前後の結果を評価する際便利
第25章 テスト駆動開発のパターン7. 明示的なデータ- テストでマジックナンバーを使うのはアリ- 入力数字と期待値計算に使われた数字の関係性が読み取りやすい- 仮実装もやりやすくなる
テストを書き始めていくためのTips1. 1歩を示すテスト2. はじめのテスト3. 説明的なテスト4. 学習用テスト5. 脱線はTODOリストへ6. 回帰テスト7. 休憩・やり直す・安い机に良い椅子第26章レッドバーのパターン
第26章 レッドバーのパターン1. 一歩を示すテスト- 明白なものを取り除いた後に残るテストが、これから書くテスト- トップダウン or ボトムアップどちらからアプローチしても良い2. はじめのテスト- 本物に近いテストから書かない- すぐに書けそうなテストから始める3. 説明的なテスト- TDDを普及させるには、テストコードのように知識を共有する
第26章 レッドバーのパターン4. 学習用テスト- 依存パッケージのテストを書いておくと、バージョンアップ後の機能変化を検知しやすくなる5. 脱線はTODOリストへ- 脇道に逸れたくなるけど、、仕事に戻りましょう6. 回帰テスト- 機能追加等の際、システム全体のチェック作業に立ち返って想定外の異常が発生していないかを調べるテスト- 不具合報告 → 不具合を再現させる最小テストを書こう
第26章 レッドバーのパターン7. 休憩・やり直す・安い机に良い椅子- 休憩:- アイデアを得るために必要- 今日のゴールは妥当だったか?- やり直す:- 手詰まったら思い切って実装し直すことも手- 安い机に良い椅子:- 椅子はもちろんだが、机もこだわったほうが良いと思う(持論)
テストを上手に書く上での様々なTips1. 小さいテスト2. Mock Objectパターン3. Self Shuntパターン4. Log Stringパターン5. Crash Test Dummyパターン6. 失敗させたままのテスト7. きれいなチェックイン第27章テスティングのパターン
第27章 テスティングのパターン1. 小さいテスト- そもそも大きなテストを書く必要がない実装を心がけるべし2. Mock Objectパターン- ネットワーク越しのリソースに依存させない- テスト速度UP、信頼性向上、可読性向上3. Self Shuntパターン- テストケース自身がMock Objectのように振る舞う書き方で、あるオブジェクトが他のオブジェクトときちんとやりとりしているかをテストできる
第27章 テスティングのパターン4. Log Stringパターン- メソッドが正しい順序で呼び出されているかをテストするパターンで、文字列を活用する- Observerパターンの通知順番テストで使える5. Crash Test Dummyパターン- 仮実装でシミュレートする。例外テストする際に便利- 無名クラスはPHPでも7以降からサポートされている
第27章 テスティングのパターン6. 失敗させたままのテスト- 実装が途中でもコードを書くのを終わらせる時に有効- 最後に書いたテストをわざと失敗させることで、次回コードを書く際にどこから着手すべきかの目印にする- ただし個人で開発している時に限る7. きれいなチェックイン- チームで開発している場合はテストを全て通した上で終えること
速やかにテストをグリーンにするためのTips1. 仮実装を経て本実装へ2. 三角測量3. 明白な実装4. 一から多へ第28章グリーンバーのパターン
第28章 グリーンバーのパターン1. 仮実装を経て本実装へ- 動いていることには、動かないことよりも価値がある- 心理的に安全- 目の前の問題に集中できる2. 三角測量- 仮実装から本実装へ移行させる為に有用
第28章 グリーンバーのパターン3. 明白な実装- 仮実装や三角測量せずともすぐに書けるコードは書いちゃおう- まずは動くコードを、次にきれいなコードを4. 一から多へ- オブジェクトのコレクションを扱う操作を実装する時に有効- まずは単数が通るように実装- 続いて複数が通るように実装し直す- 変更の分離も可能
1. 実際にテストコードを書く時、何に気をつけるべきかが分かった2. テストコードを書く時にマジックナンバーは意図して頻繁に使っていたので「やっぱりな〜」と思った3. 仮実装、大いにアリ。実戦でもっと活用したい4. Exceptionのテストは、現場で十分やれてない気がしている。今後積極的に書いていく5. Self Shuntパターンでのテストコードはあまり発想が無かった。現場に活かす第25~28章を読んでみての感想