iOS Test Night #5 に参加した時のメモ
| 時間 | 内容 |
|---|---|
| 19:15 | 開場 |
| 19:30 - 19:35 | 会場説明など |
| 19:35 - 19:50 | 15分枠(1) : Yusuke Hosonuma：「Property-based testing with SwiftCheck」 |
| 19:50 - 20:05 | 15分枠(2) : toshi0383：AbemaTV iOSチームにおける継続的ナントカについて |
| 20:05 - 20:20 | 15分枠(3) : yokoyas ：「単体テストのハジメ |
| 20:20 - 20:25 | 準備＆乾杯 |
| 20:25 - 20:30 | 告知タイム |
| 20:30 - 20:35 | 5分枠(1)：star__hoshi：「VIPER Architecture から学ぶ Dependency Injection」 |
| 20:35 - 20:40 | 5分枠(2) : takasek：「テストを書かない言い訳をした結果② -負債にならないテストを求めて-」 |
| 20:40 - 20:45 | 5分枠(3) :nemoto_tadashi：「手動リグレッションテストをE2Eテストに置き換えてみて、分かってきたこと」 |
| 20:45 - 20:55 | 10分枠：tamaki： What's New in Testing!!! |
| 20:55 - 22:00 | 懇親会(★机を中央にうごかします(お手伝いお願いします)★) |
| 22:00 - | 解散 |
Yusuke Hosonuma：「Property-based testing with SwiftCheck」 @tobi462
Property-based testingとは
多数のランダム
関数型Haskellの「QuickCheck」
QuickCheckのSwift実装 SwiftCheck
XCTestに組み込める
Swiftzの
具体例
足し算のテスト
XCTest
1 + 2 = 3のテスト
テスト用の入力値を選ぶ技術
SwiftCheck
足し算の性質
結合法則を満たす
x + y == y + x
x + 1 + 1 == x + 2
property("足し算は、結合法則を満たす") <- forAll { (x: UInt, y: Unit)
return add(x, y) == add(y, x)
}
100個ものランダムな値でテストされる
ランダムだけれども、小さめの値からテストされている
失敗すると、値が「１」のケースでテストがパスしなかったみたいなエラーがでる
x * y
掛け算にして落としてみる
SwiftCheckとは
配列の反転の性質とは
配列の反転して、さらに反転すると元に戻る法則を利用して、
property("") <- forAll { (xs: ArrayOf<Int>
テストとして、性質を定義
FWが繰り返しランダム値で、テストを事項
XCTestと組み合わせて使える
Property-based testing
Arbitrary
「任意の」といった意味
Shrinking
「収縮する」といった意味
より小さな値にする役割
実践的なユースケース
1 Encode/ Decode
mwarito
大変
プロパティが多いと描くのが大変
同じ入力値を使うと入れ替えを検出できない
テストを書く労力に見合っているか
Encode -> Decodeしたものは同じ
Dog構造体
DogをArbitratyプロトコルに準拠させる
Arbitratyに準拠したので、ランダムに生成
2 遅く明確なアルゴリズム vs 高速なアルゴリズム
アルゴリズム
明確な書き方をするとだいたい遅い
高速にするとだいたいコードが複雑にjなる
テストの難しさ
性質を考える
入力値が同じであれば、同じ結果になる
コールスタックが行なわれない場合遅くなる
chooseで、値の範囲を制限
3 ランダム性に基づいたアルゴリズム
ケース
ダンジョンマップの生成
ダイスロール
性質を考える
マップは必ずコールに繋がっていること
マップに到達できない部屋がないこと
まとめ
性質に着目したユニットテスト手法
多数なランダム値でテストされる
SwiftCheckで、XCTestと組み合わせて使える
「AbemaTV iOSチームにおける継続的ナントカについて」@toshi0383
@toshi0383 鈴木 俊裕
cmdshelf
コードレビュー支援ツール
1944テストケース
Debugビルドの最速記録
2分41秒
6分13秒 Bite
CIはほぼ常にグリーン
テストケースの
PRは平均10分程度で、まーじ可能な状態に
2017年3月にjoin
手元のビルド10分以上かかる
jenkinsのテストが遅い
jenkinsがいるMacが不機嫌
対策
テストの安定化高速化
非同期の結果を待ちすぎていた 10秒->1秒
コンパイルの高速か 型推論やめる
10回に1回でも失敗する子は捨てた
ビルドとテストにタイムアウト時間を設定
Cathage移行
ライブラリツールの中では高速かしやすい
ビルドしたバイナリやdSYMなどをコミットして運用することで、CIではクローンするだけですむ
ライブラリ側がCarthage対応していない場合
forkして頑張った
PRマージしてくるケースもあるが
Carthageを使ったフレキシブル Qiitwa
ライブラリのinfo.plistが原因で遭遇したiTunesConnectアップロードのエラー
bcsymbolmap問題
dSYMでかすぎ問題
Githubファイルサイズ制限(50MB/１ファイル)
現状Git LFSで運用
Bitrige移行
割と最近出てきたCIサービス(SaaS)
Androidや Xamarinにも対応
Linux VMもある
ビルドが安定したとしてもJenkins職人が必要な状態を脱したかった
検証の結果BitriseのElite Machineのスペック
並列1台$100
x3が最低ラインなので、$300~/月
Macのプロセス数の上限解放(pxctestの毒面と
pxctestで、Simulator.appは起動説に実行することでプロセス数の節約
テス
トのジョブと、ペータ配布のジョブで、シュミレータを分けて指定
Makefileの設定例
fastlane scanと比べた利点
実行が早い
-showBUildSettingsの出力を比較することで、
bitrise.yml
circle.ymlやtravis.ymlと違いコミットしない
ジョブをworkflowとして設定する
workflowはsetpの集まり
Trigger Mapで、細かくworkflowを設定できる
「単体テストのハジメ」 @yokoyas000
テストしたいことは何でしょうか？
明示的な入出力
引数 -> 関数 -> 戻り値暗黙的な入出力
引数 -> 関数 -> 戻り値
大域変数
他のテストを壊すかも
UserDefaultを直接触るとっこ子が怖い
与えた変更を消し忘れると
副作用が怖い
入力は、stubという手法
出力は、spyという手法
使う
暗黙的入力をテストする為にstubを使う
大域変数から取得している
テスト時は偽物に差し替えたい
stubを使いたい
stubを使える状態にする
UserDefaultから直接取得はせずに
振る舞いを制御できるオブジェクトを挟む
制御したい振る舞いをProtocolにする
Protocolに準拠したクラスを作成する
値は、Repogitory経由でとる甲にする
Repogitoryから取得した値を使ってテストする
stubを使ってテストをかく
Protocolに準拠したstubを作成する
暗黙的入力をテストする為にspyを使う
「VIPER Architecture から学ぶ Dependency Injection」 @star__hoshi
「テストを書かない言い訳をした結果② -負債にならないテストを求めて-」 @takasek
doctest
対話的Pythonセッションおように見えるテキストを探し出し、セッションの内容を事項
プロパティベースのテスト(QuickCheck)
QuickCheckは、Haskellで書かれたコンビーネータライブラリ
関数が満たすべき
nemoto_tadashi：「手動リグレッションテストをE2Eテストに置き換えてみて、分かってきたこと」
Bluepillを使って
1OS 1mac mini 3 simulator
30分
１００%自動化1ヶ月
導入した際の効果が見えやすい
UIテストで注意すべき点
手動テストを単純に置き換えない
テストケースの期待値のずれ
正しく〇〇ができていること
どこを、どこまでチェックできていれば、正しくでいている
選択項目
レイアウト崩れ
期待値に行くまでの過程で実はチェックしていた箇所
選択項目など
テスト区分
UI変更
API変更
仕様に強く依存
E2Eテスト以外で担保できる部分を増やして行く
Postmanを使ったAPI振る舞いテスト
WebView
UnitTest、FunctionalTest