やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

Cardboardでもユニティちゃんを表示させてみた

Oculus Rift DK2で表示させたユニティちゃんを、できるだけそのままCardboardTaoVisor立体視してみます。

開発環境などは先のエントリを参照。

Durovis Dive Plugin

Durovis DiveというCardboardクローン的プロダクトがあり、そこでiOS/Android向けに簡単に立体視と視点のトラッキングを実現できるUnityプラグインが配布されています。

以下の手順で適用します。

  1. Dive SDKのページからプラグインをダウンロード(執筆時点のバージョンは2.0 r498)
  2. Assets -> Import Package -> Custom package...でインポート
  3. Project ViewのAssets/Dive/Dive_CameraをHierarchy Viewにドラッグアンドドロップ。従来のカメラを無効化(Inspectorでチェックをoff)
  4. Dive_CameraのTransformを適切に設定(Oculus Riftのときと同じ)
  5. スプラッシュスクリーンの表示が必須とのことなので、AssetsにあるDive-Splashscreen.unityをビルド対象に追加(File -> Build Settings...の"Scenes In Build"に追加)

f:id:nowsprinting:20141103153246p:plain

Oculus Riftに比べて視野角が狭いので、外周の歪みも無い(無くていい)みたい。

Androidデバイス向けにビルドする

Androidデバイス向けのビルドを行ないます。

なお、動作を試すだけなら、Unity Remote 4が使えるはずなのですが、Android版とUnity 4.5.5では同期できませんでした。

ビルドの設定

  1. File -> Build Settings... を開き、Platformの"Android"を選択します
    • ここで"Google Android Project"をonにすると、apkでなくAndroidプロジェクト(Ant版)が出力されます
  2. Build Settingsの[Player Settings...]ボタンをクリックするとInspectorの表示が切り替わり、ここでアイコンなどを設定できます
    • "Other Settings"に、"Bundle Identifier"、"Bundle Version"および"Bundle Version Code"の設定があります。"Bundle Identifier"の設定は必須です
    • "Publishing Settings"に、apkに、署名するためのキーストアの設定があります。デバッグ証明書を使う場合はキーストア未選択のままでいいようです
  3. Unity -> Preferences... -> External Tools の"Android SDK Location"を設定(選択)します
  4. これで[Build]もしくは[Build and Run]ボタンでビルドできます(出力ファイルパスを聞かれます)

コマンドラインでビルド

AndroidアプリはUnityコマンドで直接ビルドできないため、Unityプロジェクト内にビルドを実行するスタティックメソッドを作成し、それをコマンドラインから呼び出します。

ビルドメソッドの作成

まず、スクリプトの格納フォルダを作ります。Assets -> Create -> Folderでフォルダを生成。名前をEditorに変更します(namespace UnityEditorをエラーにしないために必須)。

続いて、Project ViewのEditorフォルダを右クリック -> Create -> C# Scriptでスクリプトを生成します。名前は任意ですが、クラス名と一致させる必要があるのでここではBuilder.csとしました。

using UnityEngine;
using UnityEditor;

public class Builder {

    static void BuildAndroid(){
        string[] scenes = {
            "Assets/Dive/Dive-Splashscreen.unity",
            "Assets/UnityChan/Scenes/UnityChan_hw.unity"};

        string msg = BuildPipeline.BuildPlayer(
            scenes,
            "Build/UnityChanVR.apk",
            BuildTarget.Android,
            BuildOptions.None);

        if(!string.IsNullOrEmpty(msg)){
            throw new System.Exception(msg);
        }
        Debug.Log("Build completed ");
    }
}

失敗時は例外をスローすることで、Unityコマンドが終了コード1で終了します。

コマンドライン指定

次のコマンドで、BuilderクラスのBuildAndroid()メソッドを実行できます。

$ /Applications/Unity/Unity.app/Contents/MacOS/Unity -quit -batchmode -logFile /dev/stdout \
    -executeMethod Builder.BuildAndroid

なお、

  • Unityは二重起動できないため、コマンド実行時Unityは落としておく必要があります(MonoEditorは起動していてok)
  • 出力ファイルは上書きしてくれますが、必要なディレクトリ(上例ではBuildディレクトリ)はあらかじめ掘っておきます
  • -logFile /dev/stdoutを指定することで、通常コンソールに出力されるログを標準出力に出力できます

iOSデバイス向けにビルドする

iOSデバイス向けのビルド(正確には、iOS向けのXcodeプロジェクトの出力)を行ないます。

なお、動作を試すだけなら、Unity Remote 4を使うと便利です。

OpenDiveSensor.csの修正

そのままiOS向けビルドを行なうと、Assets/Dive/OpenDiveSensor.csでAndroidJavaObjectが見つからないというエラーが出ます。このオブジェクト宣言自体が不要なので*1以下は削除します。

AndroidJavaObject mConfig;
AndroidJavaObject mWindowManager;

Oculusパッケージをプロジェクトから取り除く

OculusUnityIntegration.unitypackageをインポートしている場合、それがシーンで使用されていなくてもビルドエラー*2が出るようです。iOSデバイス向けでは使用しないので、Project ViewのAssets/OVRを削除します。

ビルドの設定

  1. File -> Build Settings... を開き、Platformの"iOS"を選択します
    • "Symlink Unity libraries"は、UnityのライブラリをXcodeプロジェクトにコピーしないため高速に動作します。XcodeプロジェクトだけCIサーバなどでビルドするのでなければonでいいはず
  2. Build Settingsの[Player Settings...]ボタンをクリックするとInspectorの表示が切り替わり、ここでアイコンなどを設定できます
    • "Other Settings"に、"Bundle Identifier"と"Bundle Version"の設定があります
    • "Bundle Identifier"は、Info.plistのCFBundleIdentifierにセットされますが、末尾は${PRODUCT_NAME}に置き換えられます
    • "Bundle Version"は、Info.plistのCFBundleShortVersionStringCFBundleVersionの両方にセットされます
  3. これで[Build]もしくは[Build and Run]ボタンでXcodeプロジェクトを出力できます(出力ファイルパスを聞かれます)

コマンドラインでビルド

iOSアプリ(Xcodeプロジェクト)もUnityコマンドで直接ビルドできないため、Unityプロジェクト内にビルドを実行するスタティックメソッドを作成し、それをコマンドラインから呼び出します。

ビルドメソッドの作成

Android向けに作成したBuilderクラスに、BuildIos()メソッドを追加します。

using UnityEngine;
using UnityEditor;

public class Builder {

    static void BuildAndroid(){
        (snip)
    }

    static void BuildIos(){
        string[] scenes = {
            "Assets/Dive/Dive-Splashscreen.unity",
            "Assets/UnityChan/Scenes/UnityChan_hw.unity"};

        string msg = BuildPipeline.BuildPlayer(
            scenes,
            "Build/UnityChanVRiOS",
            BuildTarget.iPhone,
            BuildOptions.SymlinkLibraries);

        if(!string.IsNullOrEmpty(msg)){
            throw new System.Exception(msg);
        }
        Debug.Log("Build completed ");
    }
}

コマンドライン指定

次のコマンドで実行します。

$ /Applications/Unity/Unity.app/Contents/MacOS/Unity -quit -batchmode -logFile /dev/stdout \
    -executeMethod Builder.BuildIos

Xcodeプロジェクトのビルド

生成されたプロジェクトは、Xcodeでビルドできます(Xcode 6.0.1で確認)。 Xcodeプロジェクトをコマンドラインでビルドするにはxcodebuildコマンドを利用できます。詳しくは『iOSアプリ テスト自動化入門』のChapter 6などを参照してください。

iOSアプリ テスト自動化入門

iOSアプリ テスト自動化入門

参考

Unity実践技術大全 (GAME DEVELOPER BOOKS)

Unity実践技術大全 (GAME DEVELOPER BOOKS)

ライセンス

ユニティちゃんライセンス

このコンテンツは、『ユニティちゃんライセンス』で提供されています

*1:Android向けに必要な物は"#if UNITY_ANDROID"の中に書かれているので

*2:Cross compilation job Assembly-CSharp.dll failed.

Android WearでIME (Minuum Keyboard) を使ってみた

Android向けの、小さいサイズのキーボードが売りのIMEであるMinuum KeyboardAndroid Wearに対応したと聞いて*1試してみました。

f:id:nowsprinting:20140717035208p:plain

ありがちな誤解の訂正

まず、ありがちな誤解*2について。以下を踏まえて、以降を読み進めてください。

IME on Android Wear

そもそもAndroid Wearからの入力は、音声入力もしくはGUIからのごく簡素な入力を前提とされています。 従って、プリインおよびGoogle Play Storeで公開されているAndroid Wear向けアプリには、EditTextで文字列を入力させるインタフェースを備えているものはありません。

Android Wear向けアプリでEditTextを使用することは可能ですが、Wearには(少なくとも、LG G Watchには)EditTextをタップしたときに起動するIMEがインストールされていないため、入力はできません*3

端末にインストールされているIMEは、以下のコマンドで確認できます。

$ adb shell ime list -a

これを通常のAndroid端末に向けて叩くと、IMEInputMethodServiceの実装)のID, name, packageNameなどが出力されます。

しかしAndroid Wear端末では、出力がありません(つまりIMEがひとつもインストールされていない)。

IMEのインストールと有効化

AndroidにおけるIMEは、ひとつのアプリとして端末にインストールすることができます。インストールまでは通常のアプリ(apk)と同じ手順で行ないます。

Minuum Keyboard(apkファイル入手方法は後述します)では、adb installコマンドで直接Wearデバイスにインストールします。

$ adb install -r PACKAGE.apk

インストールしたapkは、通常のAndroid端末であれば設定アプリの"言語とキーボード"で有効化を行えますが、Wearデバイスにはこの設定項目がありません。そのため、以下のコマンドで有効化を行ないます(Minuum on Android Wearの最新の手順にはime enableコマンドも書かれていますが、ime setコマンドだけで有効になります)。

$ adb shell ime set PACKAGE_NAME/.SERVICE_NAME

PACKAGE_NAMEにはapkのパッケージ名、SERVICE_NAMEにはInputMethodServiceのクラス名を指定します(Minuum Keyboardでは、インストール方法のメールに書かれています)。

これで、インストールしたIMEを使えるようになります。

Minuum Keyboardの利用

IMEを起動するにはEditTextを配置したActivityが必要です。Minuum Keyboardには、その設定アプリ内に動作確認を行なうことのできるEditTextが配置されているため、それを利用して確認します(独自のIMEをインストールした場合は、EditTextを備えたアプリも用意してください)。

1.ランチャーから"開始..."を選択し、"Minuum Settings"を探してアイコンをタップします

f:id:nowsprinting:20140717040646p:plain

2.起動には少し時間がかかります(一旦Watch Faceに戻りますがそのまま待ちます)。数秒後、MinuumのAgreement画面が表示されますので、内容をよく読んで"I agree"をタップします

f:id:nowsprinting:20140717040842p:plain

3.設定画面が表示されたら下にスクロールして、"Cheat sheet"をタップします

f:id:nowsprinting:20140717041058p:plain

4.チートシートEditText、そしてMinuum Keyboardが表示され、入力することができます。この画面を抜けるには、他のWearアプリ同様、右にスワイプします。

f:id:nowsprinting:20140717035208p:plain

Minuum Keyboardの入手

Android Wearで動作するMinuum Keyboardは、下記ページにサインアップ*4することで、メールでインストール手順とともにapkのダウンロードURLが届くはずです。

メールには、本エントリで具体的には書かなかったパッケージ名なども記載されています。基本的にメールに沿って実行していけば大丈夫なはずです。

Minuum Keyboardの使い勝手

そもそも、Android向けのIMEとしての実績があるアプリケーションで、小さいキーボードと、それに伴なうtypoを前提としてカバーする(予測変換的な)アルゴリズムが売りのようです。

ある程度typoしていても構わず入力していくと、正しい(入力したかった)単語が候補として表示されます。右スワイプで確定&スペース空け、左スワイプで一語削除と、一般的な英文であればスムーズに入力していくことができます。

ただ、記号の入力は辛いのと、老眼の人には細かすぎて厳しいような気がします。私はまだ全然大丈夫です。

現在、様々なデバイス向けのSDKを準備中のようで、下記サイトの下のほうに動画とサインアップフォームへのリンクが貼ってあります。

どのような販売形態・価格体系になるかわかりませんが、Android Wearのようにインストールに制約がある(コンシューマが簡単に使えない)デバイス向けには、SDKとしてアプリにバンドルさせる形を想定しているのではないでしょうか。

所感

Android Wearでも(設定すれば)IMEが使えるというのは面白いですね。 設定には開発者向けツールが必要なのと、インストールしたとしてもIMEを使えるアプリ(EditTextで入力させるアプリ)が無ければ使いどころもないので、すぐ実用化、一般化、となるものではないでしょう。しかし、ひとつのデバイスとして遊びどころはまだまだありそうです。

最後に。Android Wear 勉強会 #2の参加エントリも書かず、こんなの書いててごめんなさい…

*1:Android Wear対応の超小型ソフトウェアキーボード登場 | GGSOKU - ガジェット速報

*2:誤解というか出ている情報だけでは判断つきませんよねー

*3:Logcatを見る限り、特にエラーを吐くこともなく、なにもおこらない

*4:Mailing Listと書かれていますが、いわゆるMLではなく一方通行のアナウンスが送られてきます

Gradle+Androidプラグイン(0.7以降)でNDKプロジェクトをビルドする

Androidの新ビルドシステムであるGradle plugin for Androidでは、0.7からNDKのビルドがサポートされました。

が、いまだに(一年前の)0.4ベースのエントリが参照されていたり、ググると上位にいるようなので、現状をまとめなおします。

環境

  • Android SDK Build-tools r19.1
  • Gradle 1.12(1.10以上)
  • Gradle plugin for Android 0.11.0(Gradleによってインストール)

Gradleのインストール方法は、下記エントリを参照してください。

AndroidプラグインのNDKサポート

以前は、build.gradleにカスタムタスクを定義してndk-buildを実行していましたが、現在は以下のように書くことができます。

android {
    defaultConfig {
        ndk {
            moduleName "cppmodule"
            abiFilter "armeabi-v7a"
            stl "gnustl_static"
        }
    }
}

ビルドした共有ライブラリをapkに取り込むために記述していた下記タスクは削除してください。(pkgTask#jniDir()は削除されました)

- tasks.withType(com.android.build.gradle.tasks.PackageApplication) {
-     pkgTask -> pkgTask.jniDir new File(projectDir, 'libs')
- }

ビルド対象のソースは、従来のjni/ディレクトリではなく、src/main/jni/に置きます。また、以下のファイルは自動生成されますので不要になります。

最後に、local.propertiesファイル(もしくは環境変数ANDROID_NDK_HOME)にAndroid NDKのパスを定義します。(パスは各自のインストールパスを指定してください)

ndk.dir=/Applications/android-ndk-r9d/

これで、これまで通り下記コマンドでビルドが実行されます。

$ gradle build

ndkのプロパティ

ndk{}内のプロパティには、Android.mkおよびApplication.mkに定義していた内容を設定することができます。

また例えばabiFilterなどは、defaultConfigでなくプロダクト・フレーバーごとに記述することもできます。新ビルドシステムのサンプルプロジェクトndkSanAngelsでは、プロダクト・フレーバーとしてx86, arm, mips, fatをそれぞれビルドしています。

ビルド済み共有ライブラリの利用

別途ビルドした共有ライブラリ(.soファイル)を利用する場合は、src/main/jniLibsにファイルを格納しておくことでビルド時にパッケージされます。

以上で、ほとんどのケースでbuild.gradleの記述だけでNDKプロジェクトのビルドが実現できるのではないでしょうか。

だが断る

現時点(Gradle plugin for Android 0.11.0)では残念ながら、標準サポートされた機能ではスタティックライブラリ(.aファイル)を含むプロジェクトはビルドすることができません。

スタティックライブラリを含むプロジェクトでは、0.4ベースのエントリに書いた設定をベースに以下を修正してください。

1.ビルドした共有ライブラリをapkに取り込むために記述していた下記タスクは削除してください。(pkgTask#jniDir()は削除されました)

- tasks.withType(com.android.build.gradle.tasks.PackageApplication) {
-     pkgTask -> pkgTask.jniDir new File(projectDir, 'libs')
- }

2.ndk-buildで生成された.soファイルを、libs/からsrc/main/jniLibs/にコピーします。(シンボリックリンクを張るなどでも可)

task ndkCopy(type: Copy) {
    from 'libs'
    into 'src/main/jniLibs'
}
tasks.withType(Compile) {
    compileTask -> compileTask.dependsOn ndkBuild, ndkCopy
}

サンプルプロジェクト

https://github.com/nowsprinting/GradleAndroidNdkExample を更新してあります。

EasyMockをAndroidテストプロジェクトで使用する #android_tec

DalvikサポートがマージされたEasyMock 3.2がいつの間にか(半年も前に)リリースされていたので導入方法などのメモ。

尚、MockitoのDalvikサポートについては下記エントリで紹介しています。

MockitoをAndroidテストプロジェクトで使用する #android_tec - やらなイカ?

EasyMockの導入手順

  1. EasyMock : Downloadsから、EasyMock 3.2以降のzipファイル(執筆時点の最新はeasymock-3.2.zip)をダウンロード・展開し、easymock-3.2.jarをプロジェクトに追加します。
  2. テストプロジェクトのproperties -> "Java Build Path" -> "Libraries"タブを開き、"Add JARs..."ボタンをクリックしてダウンロードしたjarファイルを選択します。
  3. Downloads - dexmakerから、dexmaker-1.0.jarをダウンロードし、プロジェクトの/libsディレクトリに追加します。(こちらはクラスパスを通す必要はありません)

セットアップは、これだけです。

ライセンスは、EasyMock、dexmakerとも、Apache License 2.0です。

EasyMockの使い方

@ITさんの記事「Android Mockを利用してHTTP通信をテストするには」で書いたサンプルコードをEasyMock向けに書き換えたものをgistに上げておきました。

対応するプロダクトコードは

https://atec.googlecode.com/svn/atmarkit/usemock/trunk/UseMockExample

Android Mockを使用したテストコードは

https://atec.googlecode.com/svn/atmarkit/usemock/trunk/UseMockExampleTest

に置いてあります。

そもそもAndroid MockがEasyMockベースなので、変更箇所は以下の3点です。

  • import文をorg.easymock.EasyMockに変更
  • @UseMocksアノテーションは不要なので削除
  • s/AndroidMock/EasyMock/g

EasyMock自体の機能や使い方は公式サイトなどを参照してください。

Android Test Casual Talks #1で「Androidで使えるモックフレームワーク」をLTしてきました #androidtest

Androidのテスト系イベントAndroid Test Casual Talks #1に行ってきました。 Androidのテスト関係ネタはだいたい出尽くした感を持っていたのですが、Espressoやテストケース自動生成など目新しい話、また楽天さんの導入事例の話など、興味深いお話を聞けました。

また、自分でも下記のLTをしてきました。

Androidで使えるモックフレームワーク

スライドに貼ってあるテストコードはgistに上げてあります*1

https://gist.github.com/nowsprinting/7940486

テスト対象(プロダクトコード)は@ITさんの記事「Android Mockを利用してHTTP通信をテストするには」で書いたものです。下記リポジトリにあります。

https://atec.googlecode.com/svn/atmarkit/usemock/trunk/UseMockExample

EasyMockとMockitoの導入方法とサンプルについては別エントリでまとめています

そして(オチにも使いましたが)Mockitoについてはこの書籍に約12ページにわたって書いてありますので、より詳しくはぜひこちらをお読みください。

Androidアプリテスト技法

Androidアプリテスト技法

他の方のLTについてのメモ

@psideさん「テスト配信プラットフォームを使おう」

UATやベータテストに利用できる配信サービスの話。TestFlightDeployGateのほか、A/Bテストに特化しているというVesselの紹介。

こうして並べてみると、クローズドなUATと、広く多数ユーザで行なうベータテストで向き不向きがありそうです。私は(iOSの流れで)TestFlightを使っているのですが、Vesselは一度試してみたいです。

@dageziさん「テストフレームワークを色々触ってみた」

エンド・ツー・エンドの(UIの操作を伴なう)テストフレームワークの紹介。Robotium推しなのは元をたどればQues#3での質疑応答&懇親会で私がおすすめしたというブーメラン案件でした。

Hiroyuki Itoさん『「最強」のチームを「造る」技術基盤 ディレクターズ・カット』

楽天さんでの自動テスト導入事例。興味深かったのは、

  • まず(自分のPCで)CI環境を構築してビルドと配信を自動化、デイリーにデモできるようにしてからテストの自動化も進めていった
  • ユニットテストRobolectricMockitoでTDDで進めることで開発速度向上
  • エンド・ツー・エンドのテストはCalabash-Androidで、featureを仕様として残す
    • featureファイルは日本語でも書けるけど、楽天さんは公用語が英語なので英語で書いている
    • featureファイルを成果物として残すのは、開発者のモチベーション向上にも寄与する
  • でもExcelのテスト仕様書は必要。Excelしか読んでくれない人もいるため、Excelのテスト仕様書は必要(大事なことなので二回言いました)
  • 自動化は目的ではなく手段。目的は、Be Happy

また途中に出たATDDについては、先日のシステムテスト自動化カンファレンス2013での@ kyon_mmさんのプレゼン資料「ATDD実践入門」に歴史・経緯を含めまとまっているので興味を持たれた方は読むといいと思います。

@geotanaさん「Androidアプリの自動テストケース作成へのチャレンジ」

Android GUITARなど、テストケース自動生成、自動実行についてのお話。紹介されていたのはユニットテストではなく*2、UI操作の範囲で自動生成するというもの。

まだ色々試されている段階ということで、今後が(続報が)楽しみです。また@bols_blueさんも食いついていたので、年が明けたら私も追いかけてみようと思いました。

@sumio_tymさん「uiautomatorを使うときの一工夫」

uiautomatorで日本語入力を伴うテストを行なうためのTipsと、専用のIMEuiautomator-unicode-input-helper)を作ったよ、というお話。

"Select All"のローカライズの部分については、uiautomatorはdescription属性指定で動作できるはずなので、Android側のEditText側にdescription属性を入れてもらう方向が健全なのかなと思いましたがどうなんでしょう。@sumio_tymさんとその辺お話すればよかった。 【12/14追記】@sumio_tymさんからコメントいただきました。description属性もローカライズ対象ということなので、簡単には行かなそうですね。

@ngsw_taroさん「Espressoに関して」

Googleさんの、恐らく次世代のエンド・ツー・エンドテストフレームワークになるであろうEspressoの紹介。まだソースを読めちゃう程度の規模とのことで、スクリーンショット撮影もできないけど今後に期待とのこと。

これが上手く進めば、結合レベルはRobotiumからEspressoに置き換わり、システムテストはuiautomatorみたいになっていくのでしょうか。

感想など

テストを普通に書いている方、これから書きたい方、またエンプラ等では書いてきたけどAndroidで使えるフレームワークの情報が欲しいという方、色々いるようなのでこの手のイベントは継続できたらいいですね。

主催の@hotchemiさん、会場提供してくださったリクルートメディアテクノロジーラボさん、ありがとうございました。

*1:EasyMockの導入方法についてはこのあとエントリ書きます

*2:こちらはAndroid特化のソリューションである必要はないので、無いのでしょう

GREE Tech Talk #04 スマートフォン時代のソフトウェアテスト に行ってきた #greetech04

最近テストづいている?勢いで、GREE Tech Talk #04 : スマートフォン時代のソフトウェアテストに行ってきたのでメモ。

WAPとかCiRCUSとかHT03AとかIS01とか懐かしいキーワードが出てきたりUnityの話が聞けたりと、幅広く、そしてスマートフォンの闇の深さを再認識できた良いイベントでした。

モバイルテスティング・クロニクル

まず松木さんの講演。モバイルおよびそのテストの歴史、現在(スマートフォン時代)に求められる品質モデルの話など。

  • アプリの品質要素、iOS/Androidともセキュリティ&プライバシーのプライオリティがダントツに高い
  • プライバシー保護については、セキュリティが確保されているのが前提

ちっともスマートじゃないスマートフォンアプリのテスト事情

GREEでTest Engineering Teamを立ちあげた山本さんの講演。

  • Androidは機種が多く、ユーザから不具合報告がある端末は高い確率で社内にない
  • 同じモデルでもキャリアや国によって違う。Galaxy S4だけで12種類のバリエーション
  • IS01みたいな変態端末
  • チップセットなどの要素をもとにペアワイズ法でテスト対象機種を絞り込む
  • アプリがテストチームに渡ってから2日でリリースされるので、できるテストが限られる
  • 先月からTest Engineering Teamを立ちあげ、
    • まずドリランドでリグレッションの自動化を進めている。新規機能は手動で行なう。テスト実行環境はエミュレータ
    • 課金機能について、Calabashで実機検証環境を整えようとしている

シェアカバー率について書き損じたので引用

Test Engineering Teamについてはこちらの書籍を参照

テストから見えてくる グーグルのソフトウェア開発

テストから見えてくる グーグルのソフトウェア開発

UnityによるGameObjectとコルーチンを利用したTestingフレームワーク

GREEの奥村さんの講演。

C#ユニットテストフレームワークとしてSharpUnitがあるが、以下の制約がある

  • 1フレームで完結するものしか書けない
  • テストのツリーをコードベースで編集
  • 失敗がログでしかわからない、どのテストが落ちたのかわからない

Unityにはそれぞれ補完できそうな機能が備わっているので、これらを改善できるフレームワークUniUnitTestを作った。これは近日オープンソース化されるとのこと。

Unityで作られたアプリがiOS/Androidで動くとは言っても、環境固有の問題は発生し得る。例としてアセットをアプリにバンドルしたとき、Androidではfile:///スキームでアクセスする必要があるなど*1

Jenkinsによるテスト自動化の会社への導入

太田さん@SHIFT、岡崎さん@GREE、粉川さん@SEGAによるパネルディスカッション。皆さんドンキで買ったJenkinsさんコスプレで登壇。

  • 内部品質はアプリの売上と必ずしも比例しない
  • ソシャゲのイベント投入などで上がる売上と、その修正にかかるコストの問題。コストが見合わないなら撤退
  • テスト自動化しやすいコードは既によくできている
  • 既存のテストの無いプロダクト、テスト自動化しにくい場合は「あきらめる」も選択肢
  • できるところからはじめる
    • ステートレスなユーティリティクラスはテスト書きやすい
    • 静的検証ツールを使う。その指摘を通じて保守性の高い設計と実装をチームに学習させることでテスタブルなコードに変わっていく。これはQAからの指摘ではなく、開発チームのアーキテクト主導で実施してもらった
  • ビルドやデプロイの自動化だけでも効果はある
  • テストコードのカバー率、数などにゲーミフィケーションを導入して改善していく。1000本目のテストコードを書いた人、など

静的検証ツールのところ、詳細を質問しておきながら自分でメモ取れてなかったので引用

最後にまとめとして一言づつ。

岡崎さん「"イノベーション"と大きく構えるのではなく、"工夫"で良い。たまに大発見もあるし、日々の工夫を積み重ねれば大きな改善になる」

太田さん「欲張らない」

感想

スマートフォンのテストに関して、その最前線にいるソシャゲ業界の実情や取り組みを聞ける大変貴重なイベントでした。

特にパネルディスカッションでは、チーム・組織にどのように自動化の文化を浸透させていくか、その手段としてのJenkinsや静的解析についての話が聞けて、大変参考になりました。*2

主催のGREEさん、登壇者の皆さん、ありがとうございました。

*1:Unityわからないので間違ってるかも

*2:ぼっち開発者なのですぐに役に立つわけではないですが、逆にとても気になっている分野なのです

システムテスト自動化カンファレンス2013で「スマートフォンアプリのテスト自動化をはじめよう」をお話してきました #stac2013

テスト自動化研究会主催のシステムテスト自動化カンファレンス2013にスタッフとして参加&モバイル枠をいただいてお話してきました。

システムテスト自動化カンファレンス2013ツイートまとめ - Togetterまとめ

毒食わば皿まで

古来より「毒食わば皿まで」という言葉がありまして、これはつまり「スライドを使いまわした*1ならブログエントリも使い回せばいいじゃない」という意味なのですが、さすがに心苦しいので以下オリジナルの補足をします。

尚、スライド自体もiOSに関する記述を追記したり*2、構成を見なおしたりしています。

テストレベルについての補足

途中で言った「『ユニットテストの話はするな』という圧力」はもちろん冗談なのですが、テストレベルに関して説明不足を感じたので補足します。

スライドでは「ユニットテスト」で済ませている部分、デブサミ2012でのAndroidテスト部講演や、書籍Androidアプリ テスト技法では「モデル*3ユニットテスト」を適切に切り出してテストすべきで、テスト困難なViewとControllerはシステムテストなど上位で実施すればいい*4のではないか、という方針でした。

それに対し、現時点では「モデルだけでなく、ビューのユニットテスト」まで行なった上で、Controllerはシステムテストで担保できれば良いのではないか、と考えています。

スライドにも「(システムテストでは)日時、天気、株価、為替、乱数などに起因するJudge*5を無理にはしない」と書いていますが、表示内容や最小桁/最大桁での見栄えはユニットテストで実施可能です。

もちろんUIの変更が発生するとテストのメンテナンスも必要になってしまうのですが、システムテストレベルで(スタブサーバを用意するなどして*6)実施するテストよりも楽に対応できるはずです。

尚、Viewのユニットテストを行なう前提は以下の二点です。

  • GHUnitなどイメージ比較をサポートしているテストフレームワークを使う
  • Viewに表示内容を渡す部分が切りだされている(MVVMにおけるViewModel的なもの。ControllerにsetText()等が書かれていないこと)

まずユニットテストからはじめなければ!という方は、テスト技法からユニットテストの基礎、Mockito、Robotiumなども載っているこちらの書籍をぜひお読みください(宣伝)

Androidアプリ テスト技法

Androidアプリ テスト技法

質疑応答(12/6追記)

これからモバイルのテストをやろうとする人へのオススメは?

まず、ちゃんとユニットテストを書きましょう。 開発者テストから入れない事情があるのであれば、Monkey Talkなどでハッピーパスから入ることをおすすめします。

モバイル向けWebアプリとネオティブアプリとの違いは?

システムテストなど上層のテストでは観点や手段などはほとんど変わらないと思います。ユニットテストなど開発者テストでは差があるはず。 WebViewのテストはMonkey Talkでもサポートされています。

システムテストではスクリプトを書くスキルは必要なのか?

自分は(開発者なので)ツールでキャプチャしたものより、スクリプトを書いています。 ひとつのアプリを複数の環境にカスタマイズしている場合など*7、キャプチャしたものをコピペしたものではメンテナンスが大変。

まとめ・感想

まずスタッフとして、手応えのある、とても良いイベントだったと思っています。講演すべて聞けたわけではないのですがどれもとても濃い内容でしたし*8、なにより会場の反応が良く、楽しんでいただけている雰囲気、一体感のようなものを感じられました。

テスト自動化研究会で初の主催イベント、しかもキャパ200人。研究会メンバーで運営にあたりましたが、事前準備、段取り、また会場をご提供いただいた日本オラクル様のサポート、また何より来場いただいた方々のご協力があって大きなトラブルもなく終えることができたと思っています。

自分の発表に関しては、Tizenとか自動化ハイ(©TABOK関西)とかがウケてよかったです。ハイと言えばDIO様のあれをネタ画像に使おうかとも思ったのですが自重したのが少し心残りです。

WebViewのテストについて

Seleniumハンズオン参加者の方から質問をいただいたそうなので(又聞き)ここで回答します。

アプリ内に組み込んだUIWebView/WebViewのテストは、少なくともMonkey Talkではサポートされています。

またSelenium自体にもAndroid Driverがバンドルされ、iOS向けにはios-driverというフレームワークも公開されているようなので、そちらも検討してみてはいかがでしょうか。WEB+DB PRESS Vol.77の特集1-3で紹介されていました。

WEB+DB PRESS Vol.77

WEB+DB PRESS Vol.77

  • 作者: 中川勝樹,山内沙瑛,舟崎健治,吉荒祐一,今井雄太,八木橋徹平,安川健太,近藤宇智朗,奥野幹也,天野祐介,賈成カイ,伊藤直也,住川裕岳,北川貴久,菅原一志,後藤秀宣,久森達郎,登尾徳誠,渡邊恵太,中島聡,A-Listers,小俣裕一,はまちや2,川添貴生,石本光司,舘野祐一,沖田邦夫,澤村正樹,卜部昌平,吉藤博記,片山暁雄,平山毅,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/10/24
  • メディア: 大型本
  • この商品を含むブログ (3件) を見る

12/3追記

@dageziさんより、RobotiumでもWebViewの中のエレメントにアクセスできるとの情報をいただきました。ありがとうございました!

*1:ひとつ前のエントリ参照。でも結構アドリブで違うこと喋ってるのです

*2:そもそもこちらがオリジナルで、Quesは後から決まった話なので削った、が正しい

*3:MVCのModel

*4:Controllerの責務にフォーカスするという意味ではなく、画面遷移やUIイベントを実行すれば確認できたと言えるので

*5:自動化の三要素(Drive, Judge, Report)からこう書いていますが、xUnitで言うAssertion

*6:そもそもスタブサーバを使うテストがシステムテストと言えるか、という話もあります

*7:これはちょっと例が悪かったのですが

*8:私のが一番内容薄くてごめんなさい感でいっぱいです