Veronica Ray
LinkedInのビデオチームに所属するソフトウェアエンジニアです。以前自転車でヘラジカの間を通り抜けたことがあります。MediumのブログとTwitterでは@nerdonicaとして活動しています。
モックを使うと、プロダクションのデータが揃うのを待たずに、早くテストを書くことができます。OCMockを使わずにモックを書く場合でも、それほど多くの作業が発生するわけではありません。講演では、コードベースの多くの重要な箇所に対して簡単でメンテナンスしやすい実践的なモックを作るためのテクニックをSwiftで説明します。
My slides from #tryswiftconf! Thanks everyone for listening 💪😎💪https://t.co/cu30JgOcLJ
— Veronica Ray (@nerdonica) 2016年3月7日
テストを書いてシステムを壊したり
遅すぎてもこまる
非同期テストはしにくい、遅くなる
OCMockがあるがかなり制限がある
Mockingフレームワークはリフレクションの上に成り立っている。Swiftはリードオンリーで実行中の者を変更できない。これがSwiftを安全にしていますが。
Swiftでは自分で仕組みを作る
厳正な事実が有ります。
これをするには時間がかかる！
時間がかからない方法を紹介します。
そもそもやる価値が有るのか？本物の型を作る意味があるのか、メンテする価値が有るのか、トレードオフを考えてモックを構築すべき
モックを作る3つの理由
ネットワークがあると遅くなるので、モックを作れば早くなる。
カバレッジを上げる、エラーや例外はシミュレーションしないとテストできない。危険なソースや何かファイルを削除するとかDBを消すとかはテストでないと難しい
システムそのものが影響を受けてテストが失敗する、副作用を及ぼす、設定ファイルを書き換えてしまう恐れなど
テストを追加するのはコードベースを改善する最高の方法です。
新たにリアクティブココアを使うとかコンカレンシーを改善するとかするなら、テストを書いて壊れないようにする。テストは実行可能なドキュメンテーションである。
やるべき時は、今でしょう。
テストは最初に書いたプログラマの頭のなかに存在するうちは簡単に出来ます。何年も立って解析するより。
だからチームでテストを各文化を作るべき。
DI
デフォルトコンストラクタは引数なしに依存性を注入できる。しかし、DIコンテナを使う時にかなり問題が発生する。
タイフーンなどのフレームワークを使う時に問題が発生します。
シングルトンでいい？
DIを使う3つの理由
- 部分的なカスタマイズが簡単
- オーナーシップが明確に
- テスタビリティ隠された仕様がなくなる
Cunstructor Injection
OCMock
Stub
レスポンスをなりすます、入れ替える。
最も一般的、レスポンスを代わりに出す
Mock もう少し複雑になる
メソッドやパラメータががセットされたかチェック
部分的モック
これはアンチパタン
セットアップするだけでも大変。そして理解度、何が本物で何がモックかわからなくなる。
ベストプラクティスが登場しています、Swiftのモッキングをプロトコルで行う。
プロトコルのほうがサブクラスよりもたくさんのメリットがある。
ストラクトとクラスとの相性が良い。一貫した形でモックを造れる。
依存性がある時にプロトコルを使うのが便利。
プロトコルに準拠していればiOS変更に伴うタイプの変更などを気にしなくて済む。
所有していないタイプのモックを辞めよ
同じようなこと言っている。
よくない理由は2つ。
モックの振る舞いは外部ライブラリとマッチする必要がある。外部ライブラリを自分が理解する必要がある、そしてその実装は変わることがある。
しかし必要になることもある。
やるなら他に依存しない時
Appleのクラスをモックにするときはそのクラスとのインタラクションのみにすべきというアドバイスを頂きました。データにダメージを加える事を考えれば、良いと思います。
私自身のプロジェクトではNotificationCenterのモックかは不要、数日必要レベル、Injection作業だけですごい大変、精度高いモックは大変だった、美しくないハックだらけに。Centerはモッキングで問題を避けることが出来る、リアルノーティフィケーション送らなくて良い、でも、私としてはCenterを使って問題を解決するのは良い方法ではない
Valueタイプをモックしてはいけない
シンプルなインアウトではモッキングは要らない
モックを減らすならバリュータイプを減らせばいい
沢山コードベースがあるなら何処から始めたら良いでしょうか
どうしたらリファクタリングで参照型を値がたにするか
Imutableにしてほぼ同じ振る舞いにして共通トランジションポイントを作る。Immutableにして後でStructに変える。
見直すと、何故クラスすなのか？と考えることが有りました。必要ないケースがあった。
モックを書いて分かったこと、優良なモックは、書くのが簡単。3日使っているなら時間投資の勝ちを見直しましょう
ひつようのない情報が沢山入っているなら避けましょう。所有しない型のモックは含めない。プロパティをデフォルトバリューに設定するときは必要な物だけを設定すべし。
かく、保守する、徹底したテストを書く、どちらが良いのか
タイムトラベラーの皆さん、将来を見ていきましょう。
Swiftモッキングフレームワークはどのようになるでしょう。
3つ出てきています。
アプローチとしては独自のモックを書かなくてはいけないがHelper提供の形で期待値やリターンバリューを定義する。
これはこれら3つと違ってサポートするクラス、ストラクトを作りOCMockに近い形でやる
これは新しい世界に言っているのではないか？ファンクショナルコア、とか。インテリティブシェル？
こうしたものはおもちゃのようでまだ早いと思う。
昨日あやかさんの話で、アーキテクチャが初めて商用環境で使われているということにワクワクした
まとめ
コードベースを改善したかったらモックテストを加工、シンプルなモックを書く
QA
昨日のセッションで目覚ましアプリなど有りましたが、日付や時間に依存すると清い方法は有りますか？
遭遇したことはないです。面白いトピックかもしれませんね。
時間周りつらい，わかる…… #tryswiftconf
— ヒメカズラ (@side_tana) March 4, 2016
javaから来た人にはイメージしやすい話 #tryswiftconf
— iida (@iida_0213) March 4, 2016
「強いコードを素早く作る！ Swiftにおける実践的モック化 #tryswiftconf」をトゥギャりました。 https://t.co/bKPBKdTcqq
— トゥギャッター開発まとめ (@tg__dev) March 4, 2016
気に入った記事は はてなブックマーク
はてなブックマークアプリiOS開発チームから来ました！ はてなブックマークにはSwift特集があります！ 良い記事を見逃さないように、ご利用ください！ http://b.hatena.ne.jp/hotentry/it/Swift
そして良いまとめ記事があったらはてなブックマークでブックマークしましょう！ try! Swift の記事で盛り上がると嬉しいです！
