iOS Test Night #3 まとめ

概要

iOS Test Night #3

ブログ・Qiitaまとめ枠として参加したのでまとめます。

各発表のトピックを箇条書きでまとめていきます。

---

初めてのquickで初めてのテスト

@ktanaka117：「初めてのQuickで初めてのテスト」
発表資料

• Quick/Nimbleとは
  • XCtestと同様のテスト用フレームワーク
  • RspecやSpecta,Ginkgoなどから影響を受けている
    • それぞれRuby,Objective-C(Cocoa),Goのテストフレームワーク
• Specの基本
  • テストの文脈に沿った記述を行う
    • context,describe,it
  • expectで期待する結果を記述
• まとめ
  • テストのテストコードを書くよりも、テストケースを取り出すことがしんどい
  • テストはテスト対象のパーツを書いている時に書くべし

---

ViewController ⇄ Presenter by RxSwift

@nonchalant0303
発表資料

• RxSwiftに関する軽い紹介
  • ViewControllerとPresenterは互いにEventとStateをやり取りしている。
    • ViewControllerはユーザーのタッチイベントをEventブジェクととしてPresenterへ通知。
    • Presenterは受け取ったEventからStateを生成し、VireControllerへ渡す。
• ViewControllerとPresenterのやりとりに関するテストを書く。
  • Presenteの入出力に関するテストを書く。
    • 入力はEvent、出力はStateとして記述可能
    • 時刻への依存が強く、書きづらい
• RxTest
  • RxSwift のテストフレームワーク
  • 前述の時間に依存したテストを書きやすく支援してくれる。
    • 自分で設定した時刻でイベントが発火したものとしてテストを記述できる。

---

開発を効率化するテストのデザインパターン

@Kuniwak
発表資料

• 型による防御
  • テストの実行前にバグを見つけることで、時間のロスを減らす
  • SemanticType
    • 文脈に沿った名前付け、型の作成を行うことで可読性を向上させる
  • RegistrationToken
    • 必要な事前処理を強制することで安全性を担保する。
• テスト容易設計
  • ViewControllerFactory
    • Storyboardとの整合性が崩れた時に、テストでそれを検知できるようにする
  • State-Machine Model
    • モデルの状態数を制限し、状態遷移に着目してテストを書くことで、網羅性を維持する。
• テストの構造化
  • Parameterized Test
    • テストコードを共通化することで、テストコードの保守性を向上。
    • 共通化によって発生する問題(どこでテストが落ちたかわからなくなる)は#line を使って回避
  • 非同期テストはPromisKitを使う
• デバッグの効率化
  • Diff Assertion
    • MIRRORDIFFKIT
    • diffが読み辛いのため読みやすくするためのライブラリを作った。
• オススメの資料
  • XUnit Test Patterns

発表者によるブログ記事

---

What is FBSimulatorContro

shingo_tamaki_948

• simctl と FBSimulatorControlの紹介
• simctl
  • Xcodeに入っているシミュレータを制御するコマンド
  • デバイスの制御、アプリケーションのインストール、起動などが行える。
• FBSimulatorControl
  • 上記のsimctl に加え、複数デバイスの起動、制御が行える。
  • headlessでも動作可能、早い。
• まとめ
  • 並列起動は一見すごいがそこまで美味しくない
  • 対話的なシナリオをE2Eで行うなどには適用できそう

参考:発表者によるsimctlに関するQiita記事

---

Bluepillを使ったiOS自動テストの並列化！

@tarappo

発表資料

• iOSテストに関するつらみ
  • テストの実行時間の増大
  • 不安定なiOSシミュレータ
• Bluepillが諸々の問題を解決してくれそう
• まとめ
  • 並列化を早期に行うことはメリットである
    • 後々導入するのは苦痛
    • 最初の段階から使っていても便利な機能が多く、導入のメリットは大きい

発表者によるまとめ

---

5分でわかる! AWS Device Farmでテストしよう！

@hatakenokakashi
発表資料

• AWS Device Farmの紹介
  • テスト時に実機を用意するのは面倒
    • DeviceFarmを使えばその手間を省ける
  • iOSやAndroidアプリを実機でテストが可能。
  • iOSもAndroidもOSバージョンはかなり幅広く対応している
    • iOS7.1 ~ iOS10
  • Xcodeからipaファイルを作成し、DeviceFarmへアップロード
    • これだけで実機によるテストが可能になる

---

テストを書かない言い訳をさせてくれ

@takasek
発表資料

• テストをできるだけ書きたくない
  • テストコードと実装コードを行き来するのはコストである。
  • このコストを避けるべきだという点はレガシーコード改善ガイドにも書いてある。
• テストよりも型チェックでなんとかしたい。
• テストそのもののコストの下げ方を求む！

---

Pull Request とテストカバレッジの連携

@star__hoshi
発表資料

• カバレッジを実際に計測する話をする
  • Xcodeを使えばローカルでのカバレッジ計測は容易
    • これをPull Request に連携させたい
      • fastlane scanとfastlane actionを用いる
  • xcov
    • カバレッジの計測結果をいい感じにビジュアライズしてくれる
  • Danger
    • PullRequest にmerge 可能かチェックマークを出せる
• いいこと
  • カバレッジを計測することでテストの不足部分が可視化される
  • レビュワーの負担が減る
  • カバレッジ100%を見ることで充足感を得る

発表者によるブログ記事

---

感想

テストの知見を得るために参加したのですが、想像以上に知見が溜まりました。
テストそのものよりも、テストがあることは前提で、その次に発生する問題に対してどう対処するか、という話が耳目を集めていたように思えます。
また、テストそのものへの問題提起的な発表もあり、テスト手法だけではなく、その周りの話題も盛り上がっていました。

ありがとうございました🙏🏼