iOS Test Night #4に参加しました
こんにちわ or こんばんわ iOS Test Night #4にブログ枠で参加させて頂きました!
これはその際のレポート記事となります。
testnight.connpass.com
- イベントの目的
- 発表 (15分枠)
- 発表 (10分枠)
- 発表 (5分枠)
- 感想
- 参考リンク
- Page Object Pattern - Selenium
- Appium
- Selenium
- Danger
- Mockingjay - Github
- Bluepill - Github
- tddbc/swift_quick - Github
- Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- Behold: Image view modes(2-up, Swipe, Onion Skinについて) - Github
- テスタブルなiOS設計の例として書いてみたのがあるので、よろしければご笑覧いたらケルト(懇親会で出た話です) https://t.co/BdjrpNvPeF #ios_test_night— Kuniwak (@orga_chem) 2017年5月22日
イベントの目的
次のような目的で開催されるイベントとの事です。
本イベントはiOSにおけるテスト周りに関する知識を共有することを目的としたものです。
テスト周りに関するものであれば何でもOKです。 例をあげるとすれば以下のようなものなどです。
テストをはじめてみた&ここで苦労した このテスティングフレームワークはここがハマりどころ テスティングフレームワークをこうやって使い分けている こうやって工夫してテストしている オレが考えるiOSアプリにおけるテスタビリティの高い設計 弊社のCI/CD環境はこんな感じにしている WWDC2017前に盛り上がっておきたい 上記のような内容について「話したいことがある!」「聞いてみたい!」という方は是非参加してください。
発表 (15分枠)
AppiumからXCUITestに変え、そのためにSwiftを学び始めた話 nemoto_tadashiさん
- E2Eテストの自動化、リグレッションテスト自動化の話
- iOSは初心者だが、webの知見を持ってAppiumを使ってはじめはtry
- 結局AppiumからXCUITestに変えた↓理由
- Accessibilityを付与するレポジトリとテストを書くレポジトリが分かれていた
- 動作速度、安定性(xcunittest-driverは当時安定していなかった)動作が遅いと書くのも遅くなる
- waitもPage Object Patternを使って安定実行出来た
- 1ヶ月半でE2Eテストを実装した
- リグレッションテストの50%自動化
- Xcodeのコマンド、pxctest, bluepill, snapshotなど学べたの良かった
- 良かったこと
- 自動化にかかる工数感がイメージできるようになった
- 違うチームにも導入の検討が波及
- QAエンジニアもUIテスト自動化に興味が出てきた
- QAテスターがメンテできるようになる事が近い目標 (多く賛同を得られているエンジニアがドキュメントを整備中)
- 中途半端ではなく、一定のレベルまでUITestを行ったことで知見が溜まった
「XCUITestする時のTIPs 〜あなたを助けるXCUITestへ〜」PoohSunnyさん
スライドはUPされ次第追記します。
- Selenum実践入門のレビューワーの方
- UIテストを実践しているか?1割にも満たない挙手。したらいいじゃんは3割程度挙手
- appiumはtoo matchだった
- appiumはiosの仕様に振り回される可能性があり様子見
- どのくらいUIテストしたらいいの?
- 楽しいから書いてしまうが、半年後にメンテで死ぬ
- 最初はスモークテストが良い
- テストの数は多くない
- 旨味があって変更コストが低い部分に対して書く
- UIテストはフラジャイルになりやすい
- Page Object Patternを利用
- テストシナリオとボタンなどのコンポーネントを切り離す。変更容易性が高まる
- よくある失敗。このテスト何しているか分からない
- テスト用のメソッド名を全て日本語にする。(testのprefixは残るが)
- given, when, thenを意識する
- 4phase testが知られているが、テストがこけた時に事後状態を残した方が分かりやすいのでteardownいらないという話も。なので3Aでも
- 自分たちを助ける為にテストを書くはずが苦しめがちなのを助ける3tipsでした
発表 (10分枠)
「Pull Request時の画面差分取得の自動化」duck8823さん
www.slideshare.net
- storyboardなどの差分確認を簡単に
- スクリーンショットをリポジトリで管理
- fastlane snapshotを使った
- dangerで画像の有無を確認
- imageMagickで画像の比較
- compositとidentifyコマンドで比較できる。真っ黒なら差分なし
- Github Pull Reuest上で確認できること
- 2-up(画像を横に並べる)
- swip (画像を重ねてswipeして少しづつ差分確認可能)
- onion skin (画像を重ねて透明度を重ねて確認)
- Dangerが.xib, .storyboard, .stringsに変更が合った場合に動く
- コミットしただけでlaneが実行される
- ステータスバーは非表示に(時間がかわるので)
- webviewやアニメーションは課題。(アプリに関係なく変わったり、タイミングが難しいもの)
「UIテストの実行時間の短縮の方法」としさん
www.slideshare.net
- UIテスト自体導入している所が少ないが、近い将来出てくる実行時間という課題
- bluepillは複数シミュレータでのテストを同時に実行できる
- テストの数をシミュレータ数で割り切れる数でやると速い 、割り切れないと+1つシミュレータが立ち上がってしまうので
- bluepillはテストケースを分割できる
- pxctestはosカバレッジを取りたい時
- スピードを取りたいならbluepill
- テストの実行時間のバラ付きをなくしたい
- テストの追加、削除に対応している、自動テストをサポートするサービス。ポメラニアン。SWET製
- 不安定なテストとの検出と並列実行計画の最適化
発表 (5分枠)
「Stubる 〜Mockingjayを使ったHTTPクライアントのテスト〜」ktanaka117さん
www.slideshare.net
- APIクライアントのスタブの話
- 通信状態などの外部要因に依存したくない
- OHHTTPStubにしなかった理由、Swiftらしい書き方が分からなかった
- そこでMockingjay。Swift製
- こちらを参考に試してみた SwiftのQuickでAlamofireを使った非同期のテストを書く - Qiita
- モックとは? メソッドが呼び出されて④いることを確認するもの
- スタブとは? テスト対象のクラスの動作をサポートするもの
- Mockingjay - An elegant library for stubbing HTTP requests with ease in Swift
Application targetに入れられるっていう理由で、開発時にはOHHTTPStubs使ってるんですが mockingjayはswiftyでよさげですね😊 #ios_test_night
— Yoshikuni Kato (@yoshikuni_kato) 2017年5月22日はい、それです。Stub は間接的な入力値で、 Mock は間接的は間接的な出力を*事前に*設定して検証するものという扱いです。同じく間接的な出力を検証するものに Spy がありますが、これは事後に検証するという違いがあります。 #ios_test_night https://t.co/yFMkLOu9WS
— Kuniwak (@orga_chem) 2017年5月22日
「テストコードをアプリケーションコードと同じ階層に置きたい」kikuchyさん
www.slideshare.net - 間違ってapplicationのtargetにテストコードを入れってしまって人知を超えた目grep力が必要になる
- コマンドラインで間違えて入れてしまったファイルをtestターゲットに再配置するツールを作った
- GitHub - kikuchy/lodger: Retargeting test source files from production to test at Swift Xcode project
「開発で学んだUnitTest 5つのTips」ぐりーんさん
Quickの利用が前提です。
5つのTipsを初心者がUnitTestに取り組みフィードバックを受けた感想を発表します。
- GivenWhenThenを意識する
- itの中にはexpectのみにする
- 1つのitに対して1つのexpectにする
- テスト出来る設計にする (DIなど)
- Mockを利用し通信でのレスポンスをテストする (テストを短く、また堅牢する為)
プロダクトコードは、テストしやすいように変えるものです(TDD過激派)。テストを書いていく過程で、テストの声を聞きながらプロダクトコードも変化させていくことが大切だと思います #ios_test_night
— Kuniwak (@orga_chem) 2017年5月22日
「実践 bluepill」Noritaka Kamiyaさん
- bluepillを前回のtest nightで聞いて早速試したがいきなりCase Sensitive File Systemでは動かなかった
- 結果bluepillのコントリビューターとなった
- テストケースが多いとハングする (1000で試した)これもpull req準備中
- fastlaneでscan build_for_testing trueが出来る
- waitが挟まるテストが多い場合に効果がある感じ
- メモリは沢山欲しい
- Travis CIなどの貧弱な環境だとしても効果はありそう
- BluepillはObjective-C
- Bluepill is a tool to run iOS tests in parallel using multiple simulators.
「テストを書かない言い訳をした結果」takasekさん
- テストを書かない言い訳をさせてくれ(前回発表資料)
- 煽ったタイトルなどの結果 114のブックマークを獲得
- テストファイルへの距離が遠い
- ファイルを並べておく?レガシーコード改善ガイドにのっている方法
- ショートカットキーで対応飛びやすくなる(Command + Shift + O)など
- 足りない Testへのトグルが無い
- Testコードへの切り替えが出来るツールをapplescript + Xcode Custom Behaviorsで作った
- Xcode BehaviorsのCustomでHot KeyをTriggerしている
- Xcode Source Editor Extensionではファイルをまたぐ操作はできなかった
感想
今回はUIのテストに関する話が多かったように感じます。appiumなのかXCUITestなのかの議論も以前より進んでいて、かけるコストをに見合う部分で書いてみたいと思いました!参加させて頂き有難うございました!
参考リンク
Page Object Pattern - Selenium
Appium
Selenium
Danger
Mockingjay - Github
Bluepill - Github
tddbc/swift_quick - Github
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
Behold: Image view modes(2-up, Swipe, Onion Skinについて) - Github
テスタブルなiOS設計の例として書いてみたのがあるので、よろしければご笑覧いたらケルト(懇親会で出た話です) https://t.co/BdjrpNvPeF #ios_test_night
— Kuniwak (@orga_chem) 2017年5月22日
テスタブルなiOS設計の例として書いてみたのがあるので、よろしければご笑覧いたらケルト(懇親会で出た話です) https://t.co/BdjrpNvPeF #ios_test_night
— Kuniwak (@orga_chem) 2017年5月22日