iOS Test Night #10の参加メモ
ハッシュタグ: #ios_test_night
- @giginet
- 発表資料
- Azure Pipelines
- Travisはコンテナの立ち上がりが遅くて詰まることがある
- MicroSoft(以下MS)がやっているOSSプランだと安定しているらしいので使ってみる
- Azure Pipeline(以下AP)はCI as a serviceで去年の秋にはじまった
- APはGUIでパイプラインを組めて無料でかなり使える
- OSSは時間無制限でコンテナを10まで
- 1並列でクローズドソースは一日1時間
- Market Placeでタスクを組み合わせても使える
- macOS/Linux/Windowsのコンテナがつかえる
- セルフホスティングができる
- OSS Swiftの話は後で
- 家にあるWindowsもセカンダリにできるっぽい
- Demo
- APを走らせるためのサンプルプロジェクト https://github.com/MicrosoftDocs/pipelines-xcode
- Buildで新しくパイプラインを作れる
- 今回はforkしたリポジトリを使うのでGithubを選ぶ
- 自分のGithubのリポジトリ一覧が見える
- YAMLで書くこともできるがXcodeをぽちるとXcode用のjobが出てくる
- xcodebuildの引数は人類には難しいがAPではGUIで選べる
- save and queueでジョブが走る
- コンテナが立ち上がるのがかなり早い10秒かからないくらい
- fork元は現時点では古いSwiftでbuildしようとしてコケる
- GUIからYAMLがはけるのが良い
- その他のiOS用のタスク
- Install Provisioning Prof ile / Certificates
- 証明書をアップロードしてインストールができる
- fastlaneの方が細かく色々できる
- App Store
- App Storeへのサブミットができる
- fastlaneの方が細かく色々できる
- UI Test
- Visual Studio App Centerを使ったUIテストが可能
- appiumでも使える
- Install Provisioning Prof ile / Certificates
- SwiftPM
- 1つのジョブでmacOS/Linuxが使える
- TravisだとSwifft用のツールチェインがあるがAPはないのでscriptを書くの大変だった
- Pros
- 単純なXcodeプロジェクトには良い
- xcodebuildg叩かなくて良くて楽
- 小さなプロジェクト向け
- ライブラリにもアプリにも無料で使えるのが良い
- ジョブ定義の柔軟さ
- GUIで設定
- 履歴ある
- YAML
- GUIからYAML生成
- 単純なXcodeプロジェクトには良い
- Cons
- 型にはまってないプロジェクトに不向き
- SwiftPMで配布するプロジェクトなどはつらそう
- キャッシュが貧弱
- パッケージインストールなどが必要なプロジェクトに不向き
- 環境構築がDockerを使う前提なのでそのせいか
- azure-pipelines.ymlが難し
- 有料プランが高いきがする
- 1つ並列タスクを増やすのに月5千円?
- まとめ
- プライベートリポジトリも実質無料で良い
- 型にはまった事はやりやすい
- LinuxもあるのでOSSでも使いやすそう
- 型にはまってないプロジェクトに不向き
- @susieyy
- 発表資料
- Folioで活用しているテストについて
- 「iOSアプリ設計パターン入門」のReduxの章を書きました。
- SnapShotTestの概要
- 事前に正しい画像を用意 Reference Image
- 失敗画像 Failed Image
- 差分画像でバグを検知 DIff Image
- リグレッションテストに属する
- Snapshot Image UI TestはUIの確認に有用
- Testing Pyramid UI,Integration,Unit Testingで上の方がコストが高い
- Domain Testよりも若干コストはかかるUnit Testing
- レビュー負荷軽減
- デバイス違い、OS違い、異常系画面
- 表示状態組み合わせテスト
- 株の銘柄と画面など
- 境界値テスト
- 異常系パターンテスト
- 画面カタログ
- 状態別の画面が確認楽になる
- 新規メンバーのキャッチアップにも有用
- Markdownを自動生成している
- 画面カタログ、Viewカタログ
- fastlane snapshotとの違い
- UI Testingを活用しているのでE2Eのレイヤになる
- XCTestの層なのでコストが安く、mockなどの状態が作りやすい
- iOS SnapshotTestCaseを使っている
- テスト対象のUIViewを投げる
- What is iOSSnapshotTestcaseが良い
- 実装
- recordModeをtrueにすると画像が出力される
- FBSnapshotVerifyView(view)のようにviewを渡す
- テストコードは10行くらいでかける
- Fastlaneでスクリプト化して一発実行など工夫
- URLSessionのレスポンスをmock化
- 確認方法
- Bitriseで失敗したテストからアーティファクトをDLする
- 悩ましい問題
- CIだけTestがFailする問題が一時期発生
- Bitriseのマシンリソース不足が問題
- このタイミングで撮りたいがマシンパワーが低いとずれる
- アニメーション中にスクショを取るとリファレンス画像と差分が出てしまう
- まとめ
- メリット
- 壊れやすい
- デメリット
- テストケースやMockデータの修正にコストがかかる
- トレードオフ
- ROIを気にして入れようね
- Point-Freeで紹介されていたSnapshot Testのライブラリを紹介
- Stephen Celis氏が作った
- Snapshot Testing
- Anything
- 画像以外の状態もスナップショットをとって比較できる
- assertSnapshot(matching: vc, as: image)
- assertSnapshot(matching: vc, as: image*on: .iPhoneSe))
- Viewのフレームとヒエラルキー比較などもできる
- メリット
- @imaizume
- 発表資料
- テストを書き始めたときの話
- テスト対象の選び方
- 書き始める場所
- 致命的なところ
- 影響範囲が大きいところ
- 無理
- 書きやすい場所から書く
- 文字列の整形とか
- 小さくて入出力が明確
- 大域変数を明示的な入力に変える
- リポジトリパターン
- 大域変数をオブジェクト経由で参照
- 性別をリポジトリ化かつ抽象化
- テスト時はstubを参照
- ViewControllerをテストしない
- テストが苦しい
- 責務ごとに小さなモジュールに切り出してテストを行う
- ニックネーム決定の小さいビジネスロジックなどNicknameConverter
- テスト対象の選び方
- @akihisasen
- 発表資料
- Amebaは2018年からRx化
- RxSwiftのテストは難しい
- 3文字以上で登録可能なフォームをテストしたいとする
- ViewModelが3行未満でFalseを返す
- Observableを入力
- Observableが出力
- 流れたイベントの時間と値をまとめて取得することが難しい
- 実時間で動いているためテストに時間が書かる
- Observableをどのようにテストするか
- RxTestを使う
- RxTest
- TestScheduler
- 仮想時間を基準としてモック
- TestableObservableとTestableObserver
- スケジューラーがTestableObservableとTestableObserverを作成する
- イベントをどう扱っているのか
- Recordedというイベント生成値と仮想時間を保持している
- TestableObserberからイベントをRecordedから取得する
- Recordedの値をテスト
- 気になったTweet。TestSchedulerは強力すぎる? https://twitter.com/orga_chem/status/1118117073450700800
- @kariad_uu
- 発表資料
- Viewのテストは難しいと思っている
- View以外のテストはやりやすい
- Presenterのテストのはなし
- ViewのUnitテスト
- UIControlでタップできるViewを簡単に作る
- addTargetでイベント追加して
- sendActionでイベント発火してテスト
- Succint
- ViewのUnitテストをつくるライブラリ
- MVP前提
- subject.hasLabelなどでテストができる
- @tobi462
- SWETグループでテストを研究したりしている
- Parameterized Test
- 事前にテストデータを列挙する書き方
- JUnit5やGoは標準
- args, expectを配列で生成してループでテスト
- テストが失敗したとき
- エラー行が集約されてしまう
- assertEmptyでXCAssertに行番号とか渡す
- #lineを追加する
- しかし#lineすら書きたくない
- OSS化しました https://github.com/YusukeHosonuma/SwiftParamTest
- asert(fizzbuzz).forAll([when(1, then: :"1")のように書ける