iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -

Copyright © DeNA Co.,Ltd. All Rights Reserved.

iOSDC Reject Conference days22016/08/31(Wed)

平田敏之 @DeNA

iOS アプリ開発のテスト環境- テストをはじめる最初の一歩 -


自己紹介

平田敏之⁃ 経歴• GW の開発 → ホムペサービスの開発、 iOS アプリの開発 → SWET

⁃ SWET(Software Engineer in Test)• ミッション

⁃ DeNA サービス全般の品質向上⁃ DeNA エンジニアの開発生産性向上

• 事業サポートチーム / テスト基盤チーム

⁃ 私がやっていること ( の一部 )• クライアントアプリ周りのテスト戦略、自動テストの開発

• CI/CD 環境整備

• テスト基盤環境の開発


本発表のゴール

皆さんが、自らのアプリでテストを書き始めるそして、テストについて苦悩する苦悩する苦悩したことを勉強会などで共有する

約 1 年後 iOSDC2017 にテスト関係で発表を申し込む誰か 1 人でも iOSDC2017 でテスト関係で発表する


今日、皆さんに話すこと

iOS アプリ開発でテストってどうしていますか？ E2E テストしていますか？マニュアルテストにまかせていませんか？

テストは ( 基本的に ) 書いたほうが良いしかし、 iOS アプリ開発におけるテストって「何ができるのか」「何からは

じめたら良いか」分かっていなかったりしませんか？

iOS アプリ開発においても ( 以前より ) 色々できるようになってきています

そこで、どのようなものがあるのか ( の一部 ) を皆さんに紹介します

⁃ 色々とありますが、「コレだ」というベストのものは無く、プロジェクトに応じて利用するものは変えたほうが良い


今日の発表の流れ

最近の iOS アプリ開発のテスト環境についての紹介

1. テストを書くために• UI テスティングフレームワーク

2. 書いたテストを動かすために• 実行環境

3. 継続的にテストを動かし続けるために• CI 環境

テスト環境の例を紹介⁃ テスト環境があるときのリリースフローの例を紹介

まとめ


本日話さないこと

以下については話しきれませんので省略⁃ 自動テストのテスト戦略⁃ 自動テストの書き方⁃ UI テストを書き続けるつらみ⁃ Apple のつらみ⁃ CI 環境のつらみ• ここは少々 Kyobashi.swift#2 で話しました

ここらへんは別の機会に


iOS アプリ開発をとりまくテスト環境 ( の一例 )

UI テスティングフレームワーク

実行環境 CI

XCUITest AWS Device Farm Jenkins

EarlGrey Xamarin Test Cloud CircleCI

Appium iOS シミュレーター

iOS 実機

Android に比べるとツライ面もあるが以前よりは良くなっている

※ 他にも多数あります※



一番注意して選ぶべきところ

別に 1 つで全てのテストを書かなくても良いのです



プロダクトコードと一緒⁃ XCUITest• Apple 純正

• OS ver: iOS9 〜

⁃ EarlGrey• Google 製

プロダクトコードとは別 ( アプリがあれば OK)⁃ Appium• iOS / Android に対応

• Rspec や JUnit などが使える


サンプルアプリ x UI テスティングフレームワーク

[Swift で書かれた簡単なアプリ ]

機能説明⁃ 上記のタブをタップしたら下部の

ページが対応するページに遷移する

今回のサンプルテストは以下⁃ Action: • 上部の 2 をタップ

⁃ Result: • 下部のページが 2 と書かれたページに

遷移する

サンプルアプリ


XCUITestimport XCTest

class SampleUITest: XCTestCase {

private let app: XCUIApplication = XCUIApplication()

override func setUp() {

super.setUp()

continueAfterFailure = false

app.launch()

}

override func tearDown() {

super.tearDown()

app.terminate()

}

//test という prefix が必要

func test 上部の 2 のタブをタップするとページ 2 に遷移する () {

let pageNumber = “2”

app.scrollViews.otherElements.staticTexts[pageNumber].tap()

XCTAssertTrue(app.scrollViews.elementBoundByIndex(1).staticTexts[pageNumber].exists)

}

}

サンプルコードユニークな id を利用せずにテストコードを書いた場合の例

.exists は、その要素が存在するかどうかで true/false が返ってくる。※ 従って hidden=true でも trueが返ってくる。


EarlGreyimport XCTest

class SampleUITest: XCTestCase {

let earlgray = EarlGrey()

override func setUp() {

super.setUp()

}

override func tearDown() {

super.tearDown()

}

//test という prefix が必要

func test 上部の 2 のタブをタップするとページ 2 に遷移する () {

let pageNumber = 2

let pageLabel= “label-” + pageNumber

earlgray .selectElementWithMatcher(grey_accessibilityLabel(pageNumber )).performAction(grey_tap())

earlgray .selectElementWithMatcher(grey_accessibilityLabel(pageLabel)).assertWithMatcher(grey_sufficientlyVisible())

}

}

サンプルコード

Setup は CocoaPods を使っておこなうことを推奨。基本的に要素に unique な id をふることを推奨している。( テストを書く上では当然な行為だと思います )

要参考https://github.com/google/EarlGrey/blob/1.0.0/docs/api.md


Appium

describe “ 画面遷移テスト” do

before(:each) do

end

after(:each) do

end

let(:pageNumber) { “2” }

it “ 上部の 2 のタブをタップするとページ 2 に遷移する” do

find_element(:name, pageNumber).click()

pageTitle= find_element(:name, “label” + pageNumbe).text

expect(pageTitle).to eq(pageNumber)

end

end

サンプルコード (Rspec)Appium は XCTest や EarlGrey とはアーキテクチャーが異なる点に注意※ 左のコード以外にも必要なコードがあります。

上記のサンプルコードは Rspec なので、 describe/it などが使えます。

要素の取得には、 accessibilityIdentifier や accessibilityLabel や Xpath を使用しておこないます。上記の例では、 accessibilityLabel を使用しています。


UI テストを書くときの Tips

iOS シミュレーターの Acccessibility Inspector は便利要素に unique な id は必須

⁃ 無くても書けるが後で苦労するテスト名は分かりやすくする

⁃ 無理して英語にしなくても良い頑張り過ぎない

⁃ 単にスクリーンショットを撮るレベルにするのも 1 つの手 CI に載せておいて、結果が全員が見えるようにしておく

⁃ 手元だけで動く状態だと確実に廃れていく


自動テストの実行環境

Android に比べて非常に面倒なのがコレですよね


自動テストの実行環境 (1/2)

AWS Device Farm⁃ 利用できるテスティングフレームワークが限られている

• Appium Java Junit / Java TestNG / Python• Calabash• UI Automation• XCTest• XCUITest

Xamarin Test Cloud• Cucumber(C# / Ruby)

iOS シミュレーター• CI 環境である Mac 上で起動

• あくまでもシミュレーター

( 自前の )iOS 実機• CI 環境である Mac に接続している必要がある


自動テストの実行環境 (2/2)

AWS Device Farm⁃ 💰 定額 250 USD/デバイススロット /月⁃ 💰 0.17 USD/ 分

Xamarin Test Cloud⁃ 💰 ¥178,200(税抜き )/ 年間 → 1 日 1時間 / 1デバイス⁃ 💰 ¥682,200(税抜き )/ 年間 → 1 日 5時間 / 3デバイス

iOS シミュレーター⁃ シミュレーターだから ..⁃ ( 基本的に )mac1台につき 1iOS シミュレーター

( 自前の )iOS 実機⁃ CI 環境に接続された iOS 実機を用いる形• Jenkins などのようなオンプレミスでないと無理

• 資産をいかすならコレが良いのだけど運用がなかなか ..


CI 環境

プロジェクトの状況に応じて決めるのが良い


CI 環境

Jenkins(オンプレミス )⁃ ど定番だが学習コストや運用コストがかかる⁃ なんでも出来るが Jenkins おじさんも出来やすい⁃ 見た目に抵抗がある人も…• blueocean plugin で多少は良くなる

⁃ LTS 2.7.2 (https://jenkins.io/changelog-stable/)

CircleCI( クラウド )⁃ さくっと簡単に利用できる優れもの• ただし iOS は有料になってしまいました…

⁃ Bitrise というのもあります

⁃ 痒いところに手が届かない⁃ Enterprise版もある

https://jenkins.io/changelog-stable/


Jenkins 2.7.1(LTS) + blueocean plugin

Jenkins も進化しています


今回紹介するテスト環境一式

Jenkins x XCUITest x iOS シミュレーター

※ この環境だとさくっとすぐにはじめられます※


iOS アプリ開発のテスト環境の例 (1/2) lane :test do scan( sdk: 'iphonesimulator', device: ENV[“device”], workspace: "sample-ios-swift.xcworkspace", scheme: "sample-ios-swift", configuration: "Debug", output_directory: 'test-report/', buildlog_path: 'test-report/', output_types: 'html, junit', clean: true )end

Jenkins x XCUITest x iOS シミュレーター

XCUITest• テストの実行は fastlane/scan を使用• 実行する device は環境変数で渡す• テストの結果は JUnit形式、 html ファイルで出力

Jenkins (Mac 上で動作 )Jenkins の job の設定• ビルドパラメータを用意• 対象 branch

• ソースコード管理 (Git) での Branch Specifier で利用する• 対象 device

• groove script で動的表• Dynamic Parameter plugin を利用• xcrun simctl list コマンドを使って iOS シミュレーター一覧は取得可

能• ※ 実機の場合は mobiledevice を利用すると ID も取得できる

• ビルドのシェルの実行でテストを実行• fastlane test

• 出力結果を集計して表示• JUnit plugin を利用

• 出力結果を slack に post• slack plugin を利用

fastlane の例


iOS アプリ開発のテスト環境の例 (2/2)

Jenkins におけるテスト結果の表示⁃ 右画像のように表示される• 全てが成功した場合の例

Jenkins におけるテスト結果の通知⁃ Slack に下画像のように通知される⁃ テストが落ちた場合は、 mention が飛ばされる


テスト環境がある場合のリリースフロー例

1. WIP で PR を出す

2. 機能を実装する

3. 上記機能のテスト観点を記述しレビュー依頼⁃ 主に QA担当者がチェックする⁃ これにより手動で検証する箇所を把握する

4. 上記機能のテストコードを実装

5. PR中においてはテストフレーズでテストを動かす⁃ 例 ) build this please: アプリをビルドする⁃ 例 ) test this please: 自動テストを実行する

• これを詠唱のように長くしてみようというアホな案を出したが、当然却下された ..

6. コードのレビューはテストが全て通った後におこなう

7. 全レビュー後、 merge8. QA検証へ

⁃ 自動テストで担保している箇所は特にやらない


まとめ

テスト周りは以前より色々とできるようになりました

開発環境と同様にテスト環境を整えるのはプロダクトにおいて重要

iOS アプリ開発のテスト環境を用意してみましょう⁃ 環境を変えやすいようにしつつ作るのがベターです

そして、テストをどんどん書いてみましょう⁃ その先の苦悩は別の勉強会で

iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -

Technology

Transcript of iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -