3/3 モックオブジェクトをより便利にする #tryswiftconf
try!Swiftのセッションまとめシリーズです。Jon Reidさんの「Making Mock Objects More Useful」についての記事になります。
資料
内容
- Swift環境でどうモックオブジェクトを作るのか
なぜモックオブジェクトが必要なのか
- レストランの例
- プロトコルでラーメンを作るメソッドがあったとする
- 何杯、何味、トッピングは何かを決める
- コンプリーションハンドラーが通常では必要
- ウェイターのコード
- 今はとりあえずハードコートしていく
- このメソッドどうやって定義していく？
- モックcookを作る
- cookRamenメソッドの実装をする
- 実際に料理はされない
- どうやって料理されるのかを確認する
- ユニットテストではモックcookを作る
- orderメソッドを使ってcookRamenを作る
- アサーションで検証
- 呼び出されたかどうかはbooleanを用いるなど
- しかし課題がある
- 情報が保存されない
- メソッドが呼び出されたということしかわからない
- 代わりに何度メソッドが呼び出されたかを記録していく
- メソッドが呼び出されてエラーが出た
- テストをやったことで見破ったということ
- 後々リファクタリングするときにも役に立つ
- 引数
- 何杯のラーメンか
- スープのタイプを決める
- 最も直近のセットしか通用しない
- 直近さえあれば大丈夫
- プロパティを名前を付けて明確にしていく
- 決まりごと
- エラーメッセージへの効果は？
- そのままだとエラーメッセージがいいものではない
- エラーが起きても2がなんで3であるかはわからない
- アサーションの表明違反
- トッピングの配列は？
- トッピングの順番を変えた場合でも正しく動いてほしい
- 配列は順番は気にしたくない
- もろいテストの例
- 非常にセンシティブ
- 今日通過しても明日壊れるかも
- ユニットテストで担保して大胆な変更に耐えうるようにしたい
- コードが進化し続けられる
- テストの脆さを弱める
- クロージャを特定し、定義を特定する
- 重要でないことは無視している
- Booleanを返すトッピングを渡す
- 期待した値と実際の値を教えてくれる
- テストが失敗した場合
- わかめではなくのりを受け取ったら
- エラーメッセージとしてはいいものではなく、素晴らしいものではない
- データ量が多い時に大変
- 実際の値は見えるけど期待されているものがわからなくなる
- Hamcrest Matchers
- Jモックの一部として開発されたもの
- 様々な言語で使われている
- マッチャーは値を評価するもの
- ミスマッチがあったら細かく期待値と何が違うのかを説明してくれる
- 結果がマッチしていればいい
- ミスマッチの説明は関連として与えられるラベルを付けて何を確認しているのかを特定していく
- チャーシューに変えてみる
- 期待値と実際の値が出てくる
- 細かく情報が出てくる
- 各パラメータの全部を使ったらどうなるのかはequalToというマッチャーを使えばいい
- スープの種類を気にしないならanythingマッチャーを使えば良い
- fakeオブジェクト
- 実際のオブジェクトがエクスペンシブなとき、信頼性が期待できないとき、グローバルステートを変えてしまう可能性がある時に使う
- より強力なモックオブジェクトを作るには
- アサートにメッセージを加えればいい
- equal、Predicateを使ってテストコードの柔軟性が良くなり弱さが軽減される
- テストをしてリファクタリングをしていくこと
- 重要なものに反応しつつも些細なことには気にしなくても
- 竹のようにしなやかに
その他このトークに関する情報源
- モックオブジェクトをより便利にする | try! Swift Tokyo 2017 #tryswiftconf Day2-11 聞き起こし - niwatakoのはてなブログ
- [速報レポート] try! Swift TOKYO 2017 2日目 午後Ⅰ #tryswiftconf ｜ Developers.IO
