https://github.com/appium/appium/releases/tag/v1.6.0 support XCUITest(WebDriverAgent) to test against Xcode8 x above iOS9.3 BTW, this feature has some unstable/known issues support UI Automator 2 for Android I already tried previous its beta version in my company, and then I issued some problems to Appium and it already fixed. I’ll switch to this new version from previous 1.5 in…More
Tag Archives: iOS
minimal ruby client for WebDriverAgent
WebDriverAgent developed by Facebook is one of WebDriver tool which run on iOS. Previous some posts, I investigated this module. And now, I develop minimal wrapper Ruby cli client to help some operations. https://github.com/KazuCocoa/wda_client I implemented some operations such as taking screenshots, getting source tree, status about the driver and install arbitrary app to the…More
[iOS]XCUITestを既存サンプルコードに適用してみた
別用もあって、XCUITestをちゃんと触ってみました。 XCUITestに対して多くのプロジェクトで問題になるのって、多分既存コードに組み込むことができるか？だと思うのですよね。(私もそうです) なので、iOS6.0をdeploy targetにしているAppiumのサンプルコードを引っ張ってきて、それを7.0にあげた状態で動くか、というところから確認してみました。結果的に、アプリは7.0を保ちつつ、XCUITestはiOS9.0を対象にしてテストを回す、ということができました。Xcode8頃から怪しくなりそうな気がしているInstruments越しのUIAutomationを見ると、できるところからiOS9系だけでもXCUITestを視野に入れ始めたほうがよさそうですね。 修正したコードは以下に入れています。 git clone して、iOS9シミュレータをターゲットに設定して command + u で実行できます。 https://github.com/KazuCocoa/XCUITestExample/tree/master やったことは、 サンプルコードを取得する iOS7.0をミニマムにする XCUItestのターゲットを追加する 幾つかのテストコード書く(ついでに、accessibility付与したり、要素の結合したり) https://github.com/KazuCocoa/XCUITestExample/blob/master/TestAppUITests/TestAppUITests.swift accessibilityIdentifier や title、private methodへの切り出し くらいです。 そのほか Storyboardから、 accessibilityIdentifier を設定できるようになっていました。Storyboard中心になるのは、実装とUIを切り分けできているので良いのではないかなと思います。 ただ、動的に変化する要素に対してaccessibilityIdentifierを付与する、というのはやっぱりコード読み書き必要だし、テストコードはやっぱりSwift/Objective-Cになるだろうので、中身見ることができる人は必要、というのは変わらなくて良いのですけどね。 XCWaitCompletionHandler がwaitとしてつかえそうだったりと、Instruments越しのUIAutomationよりは、個人的に安定した並列実行とかもできるのでは？と少し期待。 これの成果物、Amazon Device Farmなんかにも適用できるかなー。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review,…More
[iOS]XCUITestを少し追って試しにシナリオを書いてみる
XCUITestがXcode7から利用できるようになったので、少し追ってみたので、メモ。 まだ正式に導入するとか、評価したとか、そういう話ではないです。 以下は、Xcode7.0で適当なXCUITestを書いたあと、コード上でメソッドを追った時の情報をもとに引用しています。Online Documentなどでは違うところがあるかも。また、 Swift をベースに追っています。 accessibility systemを使って要素を特定する /*! Protocol describing the attributes exposed on user interface elements and available during query matching. These attributes represent data exposed to the Accessibility system. */ どうやら、XCUITestはXCTestを拡張し、さらにはAccessibilityの機構を使うみたいです。ひとまず、UIAutomationのために埋め込んだaccessibilityIdentifeirなど、そのまま流用可能のようです。 ということは、すでにUIAutomationを使いシナリオを記述している人は、テストシナリオを記述する粒度は変われど、同一のシナリオを記述することは可能かもしれないです。 例えば、 public protocol XCUIElementAttributes には が定義されています。これは accessibilityIdentifier の要素を指しているらしいので、accessibilityIdentiiferでつけた要素を特定する、ということは従来のUIAutomationと変わらず実施できます。 この要素特定には、 と の2種類が使えそうです。見た感じ。(まだちゃんと使ってはない) また、accessibilityベースではなく、より実装に依存することになりますが実装対象のUIButtonといったUIKitの要素単位を取得するためのインターフェースとして が宣言されているようです。 ここら辺は、UIAutomationで取得できていた要素を、XCUITestで参照できるようにした、というもののようです。 @available(iOS 9.0, *) のある XCUI* 群…More
[iOS]UIAutomation will be going away and focused on XCUITest
そこまでXCUITestを調べてなかったのですが、最近のFacebookのWebDriverAgentに少し気になるissueのコメントを見つけました。 issueはこちら。 ★ いくつかピックアップすると、 There are a number of limitations currently with XCTUI testing, but we will need to start with the groundwork, since it’s possible that UIAutomation is going away in the next major Xcode release. > https://github.com/facebook/WebDriverAgent/issues/7#issuecomment-140745640 The old UI Automation support in Instruments is deprecated. UI testing in XCTest is the replacement,…More
Stetho and PonyDebugger support finding elements
You know for finding elements is the first step to describe GUI Testing scenarios. For example, you need to find accessibilityIdentifier, accessibilityLabel, text and so on to describe GUI test in iOS with UIAutomation or Appium. In Android, you need to detect contentDescription or text and so on. In usually, anyone use Appium Inspector or…More
iOS向けBDD Toolsをいくつか使ってみた
OBJC #15 TESTINGを読んでで並べられていたBDD Toolsを使ってみました。今更感あるものもありますが、そこは復習込みで、という感じで。 Swiftで書かれたものに関してはGitHubにサンプルを作りました。Objective-Cのものは確認程度。あとはXcode 6 Beta時代のTDDチュートリアルを行ってみました。Xcode6.1.1環境で私は実施したので、いろいろAPI変わってて辛かった… Objective-C時代のBDDフレームワーク Cedar Kiwi Specta Pure Swiftで開発されているフレームワーク Quick https://github.com/KazuCocoa/sampleQuickSpecs Sleipnir https://github.com/KazuCocoa/sampleSleipnirSpecs あと、ついでにBDDのチュートリアル。 https://github.com/KazuCocoa/sampleTddInSwift XCTestを使った例 サンプルを使ってみたところと、ざっと見た感じ、Quickは良さそう。Sleipnirは、最近はさっぱり開発が止まっている様子。黒魔術な気がしたSleipnirも、XCTestを使っていないという点で面白そうでした。 Onjective-Cも、知名度も合わせてKiwiを使っていたのですが、Spectaを使ったほうがよかったかもなと感じました… ただ、SpectaはQuickの開発に本腰入れている感じがするので、今からならSpectaよりもQuickのほうが良さそう。 あと、やはりモバイルアプリはコードレベルでテストを充実できるのはModel、頑張ってControlerレベルですね。Viewははやり実際に描画させないといけないので、AppiumとかCalabashとかが必要そう。More
モバイルアプリのCIサービスが増えてたのでいくつか使ってみた
iOS/AndroidのCIサービスがまた増えてきたようなので、少し触れてみました。安定性はやはり以前からあるものが良さそうですが、今年は選択肢の多様化と価格競争も進みそうですね。あとは対Enterprise向けサービスも今はTravisだけですが他の選択肢も出てきそう。 今まで触れたことのあるCI環境 Travis CI, Travis CI Enterprise Wercker CloudBees Hosted CI 新たに触ってみたもの GreenhouseCI Ship.io Circle CI 試したことは、適当なサンプルプロジェクトを、GitHubのPushなどを契機にビルドするということです。それぞれのサービスの制限(ディクス容量や、時間制限など)までは確認していません。 GreenhouseCI ビルド対象はRepository URLの直接指定で行います。Publicなものであればそのままビルドすれば良いのですが、username & passでのログインやSSHの利用が提供されているので、private repositoryも対象にすることができます。 ビルド設定すると、Cloneしてきて、Android/iOSを識別、いったんビルドを試します。その後、スキャンしたビルドオプションをプルダウン形式で選ぶことができるので、そこで次回以降実施するものを選ぶことができます。 GitHubのWebhookに所定のURLを設定したら、GitHubへのイベントをきっかけにCIを回すことができるところまでサポートされている模様。 Ship.io GitHubに接続し、リポジトリを指定してビルドを開始します。こちらはまだBeta版らしく、動作が重たいです。 重たかったので、ちゃんと試せていないです… Circle CI Android、iOS共にビルドできそうだったけれど、iOSをビルドしようとすると以下のような文言が表示されました。まだBetaなので、気長に待つことが必要そう。 Warning: Sorry! Your build didn’t run because we are still adding capacity to the iOS beta and haven’t enabled your organization yet. We know…More
Objc #15 Testingを読んで
ワザノバの記事で知ったのですが、iOSに特化して、特定のテーマごとに発信しているブログを覗いてみました。 その中に、Testingに話題を絞って話している回があり、面白かったのでまとめてみます。 Issue #15 Testing Behavior-Driven Development What Should I Test?という問いかけから始まり、BDD DLSの話、BDDフレームワークを使いながら、BDDに関して説明している記事。以下の流れで実際にBDDフレームワークを使って、Behaviourとしてテストを記述するとこうなる、という事例を提示しています。 BDDフレームワークとその特徴を簡単に説明 機能に対するテストの記述 ただし、これはユーザから見ると何もテスト対象がどのように振る舞うのか書いていない、と指摘。 どのような要素が表示され、それをどうするとどうなる、というような記述に説明を加えながら発展 View Controllersのテストの具体例まで表示 締め 記事の中で、BDDのフレームワークとして以下を紹介。KiwiとQuickしか頭に入っていなかった… Objective-C時代のBDDフレームワークとしては以下。 Cedar Kiwi Specta Pure Swiftで開発されているフレームワーク Quick Sleipnir SleipnirはCedarに、QuickはSpectaに影響を受けているらしいです。個人的に、Sleipnirには興味が湧きました。というのも、XCTestを使っていないらしいです。実際に試して、どこまでできるのかを図らないとなんとも言えないのですが、XCTestに縛られず、どういう風にBDDとしてテストを実施するのかに興味があります。試してみよう。 Core principles • Sleipnir is not dependent of NSObject, it is pure Swift BDD testing framework • Sleipnir is not using XCTest • Sleipnir has nice…More
iOSのシミュレータを起動しようとして失敗した(Error: Could not find a device to launch. )時の対処法
時折、iOS SimulatorのDeviceが存在しない場合、Appiumは以下のようなエラーを出力します。 この場合、指定したDeviceが存在しないため、シミュレータの起動までいきついていないことを意味します。 その対処法を以下にまとめます。 Shift + command + 2 、もしくはXcodeを開いた時のメニューバーから、Window->Devicesを選択すると以下の画面が表示されます。 ここで、上の画像の矢印の先にある”+”をクリックすると、以下の画像のようになります。 表示される項目を埋め、Createをクリックすると、シミュレータとして操作可能な端末が生成されます。 この操作により、先ほど表示されていたError: Could not find a device to launch.となっていた対象の端末を生成すると、通常は問題なくシミュレータの起動が可能になり、エラーを除くことが可能になります。 なお、以下のコマンドの出力結果として、現在利用な端末リストを確認することも可能です。 結果 のようなものを得ることができるようになります。More
~ my tech diary ~ 