iOS Test Night参加に参加した時のメモ

# iOS Test Night #5 に参加した時のメモ
https://testnight.connpass.com/event/59283/

|時間	|内容 |
|-------|----|
|19:15 | 開場 |
|19:30 - 19:35	|会場説明など|
|19:35 - 19:50	|15分枠(1) : Yusuke Hosonuma：[「Property-based testing with SwiftCheck」](https://speakerdeck.com/yusukehosonuma/pbt-with-swiftcheck)|
|19:50 - 20:05	|15分枠(2) : toshi0383：[AbemaTV iOSチームにおける継続的ナントカについて](https://speakerdeck.com/toshi0383/abematv-iostimuniokeruji-sok-de-nantokanituite)|
|20:05 - 20:20	|15分枠(3) : yokoyas ：「[単体テストのハジメ](https://speakerdeck.com/yokoyas000/dan-ti-tesutofalsehazime)|
|20:20 - 20:25	|準備＆乾杯|
|20:25 - 20:30	|告知タイム|
|20:30 - 20:35	|5分枠(1)：star__hoshi：「[VIPER Architecture から学ぶ Dependency Injection](https://speakerdeck.com/starhoshi/viper-architecture-karaxue-bu-dependency-injection)」|
|20:35 - 20:40	|5分枠(2) : takasek：「[テストを書かない言い訳をした結果② -負債にならないテストを求めて-](https://speakerdeck.com/takasek/2170726-number-ios-test-night)」|
|20:40 - 20:45	|5分枠(3) :nemoto_tadashi：「[手動リグレッションテストをE2Eテストに置き換えてみて、分かってきたこと](https://speakerdeck.com/tadashi0713/shou-dong-riguretusiyontesutowoe2etesutonizhi-kihuan-etemite-fen-katutekitakoto)」|
|20:45 - 20:55	|10分枠：tamaki： [What's New in Testing!!!](https://speakerdeck.com/tamaki/whats-new-in-testing-1 )|
|20:55 - 22:00	|懇親会(★机を中央にうごかします(お手伝いお願いします)★)|
|22:00 -	|解散|

#  Yusuke Hosonuma：「Property-based testing with SwiftCheck」 @tobi462
https://speakerdeck.com/yusukehosonuma/pbt-with-swiftcheck

# Property-based testingとは
多数のランダム
関数型Haskellの「QuickCheck」

QuickCheckのSwift実装 [SwiftCheck](https://github.com/typelift/SwiftCheck)
XCTestに組み込める
Swiftzの

# 具体例
足し算のテスト
XCTest
1 + 2 = 3のテスト

テスト用の入力値を選ぶ技術
[SwiftCheck](https://github.com/typelift/SwiftCheck)

足し算の性質
結合法則を満たす
x + y == y + x 
x + 1 + 1 == x + 2

```swift
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  鈴木　俊裕

https://speakerdeck.com/toshi0383/abematv-iostimuniokeruji-sok-de-nantokanituite

[cmdshelf](http://qiita.com/toshi0383/items/f8af9f8232c28d20db4a)
コードレビュー支援ツール

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
https://speakerdeck.com/yokoyas000/dan-ti-tesutofalsehazime

テストしたいことは何でしょうか？

1. 明示的な入出力
引数 -> 関数 -> 戻り値

2. 暗黙的な入出力
引数 -> 関数 -> 戻り値
大域変数 
他のテストを壊すかも

UserDefaultを直接触るとっこ子が怖い
与えた変更を消し忘れると
副作用が怖い

入力は、stubという手法
出力は、spyという手法
使う

# 暗黙的入力をテストする為にstubを使う
大域変数から取得している
テスト時は偽物に差し替えたい
stubを使いたい
stubを使える状態にする
UserDefaultから直接取得はせずに
振る舞いを制御できるオブジェクトを挟む
制御したい振る舞いをProtocolにする
Protocolに準拠したクラスを作成する
値は、Repogitory経由でとる甲にする
Repogitoryから取得した値を使ってテストする

stubを使ってテストをかく
Protocolに準拠したstubを作成する

# 暗黙的入力をテストする為にspyを使う

# 「VIPER Architecture から学ぶ Dependency Injection」 @star__hoshi 

https://speakerdeck.com/starhoshi/viper-architecture-karaxue-bu-dependency-injection

# 「テストを書かない言い訳をした結果② -負債にならないテストを求めて-」 @takasek 
https://speakerdeck.com/takasek/2170726-number-ios-test-night

## doctest
対話的Pythonセッションおように見えるテキストを探し出し、セッションの内容を事項


## プロパティベースのテスト(QuickCheck)
QuickCheckは、Haskellで書かれたコンビーネータライブラリ
関数が満たすべき

# nemoto_tadashi：「手動リグレッションテストをE2Eテストに置き換えてみて、分かってきたこと」
https://speakerdeck.com/tadashi0713/shou-dong-riguretusiyontesutowoe2etesutonizhi-kihuan-etemite-fen-katutekitakoto

Bluepillを使って
1OS 1mac mini 3 simulator
30分

１００%自動化1ヶ月

導入した際の効果が見えやすい

UIテストで注意すべき点
手動テストを単純に置き換えない

テストケースの期待値のずれ
正しく〇〇ができていること
どこを、どこまでチェックできていれば、正しくでいている
選択項目
レイアウト崩れ
期待値に行くまでの過程で実はチェックしていた箇所
選択項目など

テスト区分
UI変更
API変更
仕様に強く依存

E2Eテスト以外で担保できる部分を増やして行く
Postmanを使ったAPI振る舞いテスト
WebView
UnitTest、FunctionalTest

# 「What's New in Testing!!!」 @tamaki
https://speakerdeck.com/tamaki/whats-new-in-testing-1