時折、iOS SimulatorのDeviceが存在しない場合、Appiumは以下のようなエラーを出力します。 この場合、指定したDeviceが存在しないため、シミュレータの起動までいきついていないことを意味します。 その対処法を以下にまとめます。 Shift + command + 2 、もしくはXcodeを開いた時のメニューバーから、Window->Devicesを選択すると以下の画面が表示されます。 ここで、上の画像の矢印の先にある”+”をクリックすると、以下の画像のようになります。 表示される項目を埋め、Createをクリックすると、シミュレータとして操作可能な端末が生成されます。 この操作により、先ほど表示されていたError: Could not find a device to launch.となっていた対象の端末を生成すると、通常は問題なくシミュレータの起動が可能になり、エラーを除くことが可能になります。 なお、以下のコマンドの出力結果として、現在利用な端末リストを確認することも可能です。 結果 のようなものを得ることができるようになります。More
Author Archives: KazuCocoa
JuliaをMacOSXにインストールしてみる
一部の統計処理な界隈で話題のJuliaを少し使ってみようと思い、手元の入れてみましたのでメモがてら。統計的な解析は、テストの分野でも大事な位置を占めるので、何かツールを学び始めようかなと思いまして。 統計処理として、以前よりR、最近ではPythonが多く使われている一方、より処理を高速にするなどを目的に実装が進められている言語です。 JuliaのWebページ JuliaのGitHub ただ、Rや最近のPython周りにくらべてライブラリ群は少ないようですし、ブログを書いている時点でも0.3.0なので、まだまだ成長まっただ中のようですが。More
JaSST 14 北海道へ参加、発表してきました
JaSST 14 Hokkaidoに参加してきました。ブログにかくまでがJaSST!!という訳ではありませんが、閉じた話しでもないので、ここに所感など少し残しておこうと思いましたので書いてみました。 1. 基調講演: Test Yourself – テストを書くと何がどう変わるか t_wadaさんの講演です。純粋に、面白かったです。Bootcampにも顔を出したことがあるのですが、実際に時間をとって、こうして話しを聞く機会ができて良かったです。 スライド 内容 全体の流れは、TDD(テスト駆動開発)の説明から、FizzBuzz問題を使ったデモ、TDDの導入により変わったことなどという流れで進んでいました。 特にデモは面白く、TDDに触れたことが無い人や、実装に沿ってテストを書くがそのテストの抜け漏れまで考えていない人らからすると、いろいろ考えるきっかけを与えてくれるような内容だったと思います。私は手元でRuby+RSpecですが、いくつか書きながらデモを追っていました。(Java+JUnitが久しぶりでパッと頭に浮かばなかったのは内緒)。 基調講演のまとめとしては、nemorinさんが既にブログを書いているのでそちらに任せ、以下では個人的な所感でも。More
Appium1.2.2 released
Appium、1.2.2が出てました。 https://github.com/appium/appium/releases/tag/v1.2.2 なにげに、インスペクタのレイアウトが変わってました。 iOSは微修正、Androidのほうが修正が多いように見えます。 個人的にiOSとして既存のテストに影響のありそうな修正は無かった。 Androidには以下が気になるところ。 まだシナリオ少ないですが、Androidは安定に向かっていて良さそう。 Android cache Chromedriver webview objects so we don’t need to start a new Chromedriver on every context switch allow chromeOptions cap object to be passed to chromedriver download all chromedriver architectures for linux (32 and 64 bit) make sure we stop adb logcat logging when ending a chrome…More
Appium1.2.1 released !!
Appium1.2.1がリリースされましたね。 https://github.com/appium/appium 既に、結構お世話になっているのですがAndroidに関してはiOSにくらべて不安定だったり、やりたいことを実現できていないことが多いのですが、今回の更新で少し良い意味で気になった箇所をピックアップしてみます。 いくつか小さな不具合修正や、使いやすさ向上は置いておいて。 iOS fix bug with parsing of binary vs XML plists retry getting screenshot if it fails fix error in getting localized strings XMLの修正や、screenshotのretry処理は嬉しい。特に、screentshotはリトライなくてここで失敗するシナリオもあったし。 あとは、Safariで操作するときの振る舞いが安定してきたみたい？いろいろ改善が見られる。 Android fix handling of IME activation support API level 10 style focused activity strings update api level dependency for the project to 19 fix bug with xpath…More
Travis CIとSauceLabsを使ってiOSをビルドしてみた
以前、SauceLabsを使った自動テストと、AndroidのTravis CIによるビルドを実行してみました。 今回はiOSを対象に実施しますが、さらに一歩進んで、 GitHubへPush => Travis CIによるビルド => Travis CIのビルドスクリプトでSauceLabsによるテスト => 結果 という流れを実行してみます。 .travis.ymlの内容以外は基本Androidのものと同一なので省略しておきます。 内容 こちらによると、今（20140721現在）サポートされているiOSアプリは、以下の模様。 7.1 (simulator and device) 7.0 (simulator and device) 6.1 (simulator and device) travis.ymlには、 language: xcode_sdk: などの要素をまずは指定してObjectiv-Cアプリのビルドスクリプトを記述します。More
SauceLabsを使ってAndroid/iOSの自動テストを外に出してみた
最近、いくつかCI環境のサービスを調べているのですが、どうせならモバイルアプリのテストも外サービスに出して、サービス開発に力を注げるような環境を構築できたらなと思いSauceLabsを使ってみました。 SauceLabsを使った理由としては、Appiumの開発に強く関わっているところだからなだけです。 良い点 各々の操作時にスクリーンショットをSauceLab側でキャプチャしてくれるので、シナリオの中でどこでキャプチャをとるとかをいちいち考えなくてよい この操作起因でAppium Serverが不安定になる懸念を除ける！ ビデオも撮ってくれる 不具合発生時の再現画面をみることができる 実行環境のメンテナンスを外に任せることができる iOSもAndroidも同時実行できる環境を用意するのは結構面倒。 Appium + Seleniium Gridや、少し頑張れば自前でも分散環境作れるけれど 自前で少し作ったことありますが、保守する所を外に出せるって、テストに集中できるのであり互いのですよね。 AppiumをOSSとして提供しているので、シナリオ自体の動作確認を手元でできる（料金体系の外でできる）のは良い 懸念点 Pricingの体系が、月々の価格によっている E2Eのテストは多くの場合実行に時間がかかるので、優先度をつけての良い取捨選択を結構シビアにする必要がでてきそう DailyやWeeklyというような間隔で実行する形でないと、例えばコミット毎とかは時間の縛り上無理そう では、内容。 Androidに関しては、実際に試用したコードも載せてます。More
CloudBeesのDEV@Clouldを使ってAndroidをビルドしてみた
Travis CI/Werckerと試用して、他にモバイルに特化したものは無いかなと思い、こちらを使ってみることに。 はじめから結論なのですが、これはJenkinsをホストして、いくつか拡張された形で使えるものです。つまり、Jenkinsを実際に運用している人であれば、学習コストもかかりませんし、使っているPluginも自由に組み合わせることができます。さらには、有用プランだと、いくつか外部サービスとの連携もサービスとして使うことができるのは良かったです。 一方、Travis CIやWercketが環境構築をtravis.ymlやwercker.ymlの管理で固定して実施できていたのに対して、こちらはこういうコードで環境をコントロールすることが難しそう。また、Android/iOSも結局はSlaveにビルドを任せるので、そのSlaveの環境をソフトウェアで管理できないぶん、個人的にはTravisやWerckerのほうが良かった。 では、内容。More
WerckerでAndroidアプリをビルドしてみた
前回のTravisに続き、Wercker★, ★でAndroidアプリをビルドしてみた。ビルド対象のアプリは同じものを使用。Werkerに登録を行い Add and applicationを選択すると、GitHub Repositoryの登録から、ビルドスクリプトの作成、実施までトントン進んだ。ざっと、作業自体10分程度で終わったのだけれど、以下に作業内容をつらつらと書く。 WerckerにはBoxとかもろもろの概念があるのですが、ここではそこら編はここでは言及していないです。 リポジトリの登録〜成果物ができるまで、後少し他を書いたくらいの内容です。More
Travis CIを使ってAndroidビルドを試してみた
CI環境をいくつか比較してみようと思います。 主な対象はモバイルアプリのビルド環境なのですが、まずはTravis CIから。 対象はAndroidです。 記載内容は、基本的には公式ドキュメントを参考にしています。 ほぼ、Androidについてくるサンプルプロジェクトと同じようなレベルのものを使用しています。More
~ my tech diary ~ 