[イベントレポート] iOS Test Night #4 に参加・登壇してきました #ios_test_night

[イベントレポート] iOS Test Night #4 に参加・登壇してきました #ios_test_night

Clock Icon2017.05.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おばんです、PLAYER UNKNOWN'S BATTLEGROUNDS(通称PUBG)という100人同時オンラインのサバイバルシューティングゲームにハマり、建造物を見るとサバイバルアイテムが落ちてそうだな、と予想するようになった田中です。早くドン勝食べたい。一緒にやってくれる人募集中です!

さて、本日は今回で4回目の開催となる iOS Test Night さんにお邪魔してきましたので、そのレポートをお届けします。

イベント概要

本イベントはiOSにおけるテスト周りに関する知識を共有することを目的としたものです。

テスト周りに関するものであれば何でもOKです。 例をあげるとすれば以下のようなものなどです。

・テストをはじめてみた&ここで苦労した ・このテスティングフレームワークはここがハマりどころ ・テスティングフレームワークをこうやって使い分けている ・こうやって工夫してテストしている ・オレが考えるiOSアプリにおけるテスタビリティの高い設計 ・弊社のCI/CD環境はこんな感じにしている ・WWDC2017前に盛り上がっておきたい 上記のような内容について「話したいことがある!」「聞いてみたい!」という方は是非参加してください。

今までのiOS Test Nightの資料についてはこちらを参考にしてください。

Connpassより引用

発表

「AppiumからXCUITestに変え、そのためにSwiftを学び始めた話」 nemoto_tadashi氏

AppiumをやめてXCUITestに変えました。

  • やめた理由その1: Accessibilityを都度振っていく必要があったから。
  • やめた理由その2: xcuitest-driverが安定していない部分もあったから。

実際にXCUITestに変更してみたところ,よかった。実行速度はAppiumと比べると早かった印象。Page Object Patternを使うことで安定した。

最終的にQAエンジニアと協力してリリース前のリグレッションテストの50%を自動化成功しました。

諸事情により作っていたものの開発は中止してしまったが、もともとWebエンジニアだったところからiOSのテストに挑戦して得られた知見には大きな価値があった。

「XCUITestする時のTIPs 〜あなたを助けるXCUITestへ〜」 PoohSunny氏

[スライドは公開され次第追記します]

XCUITestに関するTipsをご紹介いただきました。

  • TIPS1: どこまでテストすればいいんだorz
    • スモークテスト
    • 基本的な動線をカバーする
    • 落ちると重大障害になる部分をカバーする
    • これからテストを書く人はうまみがあって、変更するコストが低い部分から書いてください
  • TIPS2: UIを変更したらたくさんのテストがこけてしまったorz
    • ページオブジェクトパターンを利用した変更の局所化
  • TIPS3: このテスト何してるのかわかんねーorz
    • テスト可読性を上げるためにメソッド名を日本語にする
    • Given-When-Thenを意識してみる

「Pull Request時の画面差分取得の自動化」 duck8823氏

xibやStoryboardに変更があった場合にPRに画像が貼られているかどうかなどをDangerを使って縛ったりしています。しかし関係ない画像が貼られたり、手動でキャプチャ取るのがめんどくさかったり、どこが変わったのかわかりにくいなどの問題がまだあります。今日の話はそれらを自動化する話です。

  • スクリーンショットは fastlane snapshot を使いました。各端末、各言語でスクリーンショットを出力してくれます。
  • 各画像の差分を見るために ImageMagick の composite / identify を使いました。
  • PR管理にDangerを使っています。

今後の課題としてはアニメーションやWebViewの差分チェックや、レビューを手助けするサービスの開発などとなっています。

「UIテストの実行時間の短縮の方法」 とし氏

iOSアプリのUIテストの課題の一つにテストの実行時間が長いという問題がある。そして様々なツールがある中で、それぞれで実際にテストを実行してみたときの実行時間を測ってみました、というお話をいただきました。

その中で試行錯誤を行うことで、テスト時間を圧倒的に短くすることに成功したそうです。

「Stubる 〜Mockingjayを使ったHTTPクライアントのテスト〜」 ktanaka117

初心者枠的な立ち位置で発表させていただいたつもりです、私の発表です。

ユニットテストにおいて、外部のWebAPIに依存してしまうHTTPクライアントのテストをどう行えばよいかという話から、MockingjayというStubライブラリを使ってその部分のテストを行うという話をしました。

「テストコードをアプリケーションコードと同じ階層に置きたい」 kikuchy氏

テスト対象とテストは関連度が近いので、できるだけファイルも近い場所に置いておきたい!でもファイルを置くターゲットを間違えてしまったりするかもしれない...。それをかいけつするために Lodger というツールを作りました!

「開発で学んだUnitTest5つのTips」 ぐりーん氏

[スライドは公開され次第追記します]

初心者がUnitTestを書いてみて学んだTipsやコードレビュー時に指摘されて教えてもらった手法や気をつけることについて紹介します。

  • Given-When-Thenを意識する
  • itの中にはexpectのみにする
  • 1つのitに対して1つのexpectにする
  • テストできる設計にする
  • Mockを利用して通信でのレスポンスをテストする

「実践 bluepill」 Noritaka Kamiya氏

まずbluepillが動かない。私のMacでは動かない。自分の環境で動かないからPR出したので、私は今bluepillのコントリビューターです。

waitが挟まるテストが多い場合にbluepillの複数シミュレータを立ち上げるのは有効らしい。

「テストを書かない言い訳をした結果wwwwwww」 takasek氏

前回の発表の反響が大きかった。ありがとうございました。

テストファイルの距離が遠い話に対して便利なショートカットがいっぱいあります。でもXcodeにはないものがあるんですよ。

それを解決するためにアプリを作りました。テストを書かない言い訳をした結果、テストと実装の距離を近づけるスクリプトが生まれました。

さいごに

今回も実践的な内容が多数紹介された有意義な会でした! これまでのTest Nightの発表を踏まえた話が多かったのか、UIテストの話が多かったのを特徴的に感じました。具体的な計測時間の話も多く、ツールを使った結果どんな未来が訪れるかということがはっきりと見える会でした。

毎回毎回、新たなツールを作る猛者が現れたりするこの会、また次回も期待なイベントです!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.