最近、いくつかCI環境のサービスを調べているのですが、どうせならモバイルアプリのテストも外サービスに出して、サービス開発に力を注げるような環境を構築できたらなと思いSauceLabsを使ってみました。 SauceLabsを使った理由としては、Appiumの開発に強く関わっているところだからなだけです。 良い点 各々の操作時にスクリーンショットをSauceLab側でキャプチャしてくれるので、シナリオの中でどこでキャプチャをとるとかをいちいち考えなくてよい この操作起因でAppium Serverが不安定になる懸念を除ける！ ビデオも撮ってくれる 不具合発生時の再現画面をみることができる 実行環境のメンテナンスを外に任せることができる iOSもAndroidも同時実行できる環境を用意するのは結構面倒。 Appium + Seleniium Gridや、少し頑張れば自前でも分散環境作れるけれど 自前で少し作ったことありますが、保守する所を外に出せるって、テストに集中できるのであり互いのですよね。 AppiumをOSSとして提供しているので、シナリオ自体の動作確認を手元でできる（料金体系の外でできる）のは良い 懸念点 Pricingの体系が、月々の価格によっている E2Eのテストは多くの場合実行に時間がかかるので、優先度をつけての良い取捨選択を結構シビアにする必要がでてきそう DailyやWeeklyというような間隔で実行する形でないと、例えばコミット毎とかは時間の縛り上無理そう では、内容。 Androidに関しては、実際に試用したコードも載せてます。More
Tag Archives: automation
GitHub API v3のWebHookと戯れてみた
最近、GitHub API のWebHookを使っていろいろ自動化をトライしてみてます。なので、少し調べてみた。 WebHook自体は以下のURLを参照ください。 – https://developer.github.com/webhooks/ ここでは、私が実際に行った作業の備忘録かねて残していく、というスタンスで記載します。 WebHookの登録 通常のGitHubなら、SettingのWebhooks & ServicesからWebHookを登録することができます。(2014/07/06時点)More
Appium1.2.0released
ついにAppium1.2.0がリリースされましたね！！ XPathの文字化け対応が入るバージョンだったので、なにげに待ちに待っていた。 あと、ふと見たらコードネームが1.2.0ではついていなかった・・・ XPath strategyの文字化けが修正されていて、ruby_libのfindが使えるようになっていた。 ruby_libのfindとは、 にて指定したvalueを含む要素を取得する、というやつ。XPathの力のおかげで、単なるaccessibility_id strategyよりも変更に強いシナリオを記述できるようになるメソッド。 これで、例えば”あるボタンに表示される一部の文字が変数のように変化するが、他は変化しない”というような場合でも、その要素を取得可能な変更に強いスクリプトに落とし込むことができる。会社で部分的に修正を施して問題なく動作するようなら、社内に広めることができる状態になったと言えるかもしれない。（継続して開発する上で、やっぱり定型動作を機械が回してくれるのって、ありがたいのですよね）More
Gradleタスクの”<<"の有無
Androidのビルド管理がGradleになり、そのGradleタスクを使っていろいろと人手でやっていた箇所もビルドプロセスに手を加えて機械に任せていこうという段階になりました。 GradleタスクをRubyのRakeタスクのように簡単に扱えるようになりたいというのもあり、少し学んだことをメモ。 ここでは、taskのdependsOnの関係と、常に実行されるtask、されないtaskを区別することが目的。 こんな感じで書いたGradleタスクを例えばAndroidのサンプルプロジェクト（hello worldレベル）に対して以下のように実行すると・・・ $ ./gradlew assembleDebug こちらでは、setUpParamsのみが常に実行されます $ ./gradlew assembleDebug reBuild こちらでは、setUpParams、ビルドのあるにreSetParams, reBuildの順で実行されます。 1つ、つまづいたのはtaskにある” << "の存在。 これがついている時は、引数に指定しないと評価されないが、ついていないときは常に評価される。 http://www.gradle.org/docs/current/userguide/build_lifecycle.html のライフサイクルみつけて、なるほど、と思ったのでした。More
（テスト）自動化はROIでするorしないを判断しないといけない？
テスト自動化であったり、自動化の話しが出てくると、多くは費用対効果（ROI）の話しが上がりますね。 一方で、私はROIしか話しに出てこないことに疑問を持っています。 では、何で自動化の利点を数値としてどう計るかに関して、最近、BABOKをさらっと読み返したのですが、費用対便益(費用便益分析, Cost-Benefit Analysis)のほうがROIよりもまだしっくりくるかもと思いました。 ※ここでは、”何を自動化するか”に関する議論は全くしていません。 まずはROIの定義から。 ROI: 投資利益率（とうしりえきりつ） 投資額に対してどれだけ経常利益を生み出しているかを見る尺度である。 (投資利益率) = 100 * (当期純利益) + {(期首総資本+期末総資本)/2}More
CIで何回も回すから味の出てくるテストケースを考えてみる
テストの価値の話し。 前提として、銀の弾丸のように様々なシチュエーションに耐える話しではないことは断っておきます。 ソフトウェアテストを知っている人の場合、ランダムな値をテストのインプットとすることは良くないと考える方が多いと思います。一方で、最近ではコミットごとにCIをぐるぐる回すような開発環境も日常化してきました。その、CIをコミットごとにぐるぐる回す環境を活かし、ランダムな値をテストに取り入れ、より効率的なテストができないかとここ数ヶ月思っています。 結論から言えば、同値に区分される入力値に関して、1つのテストケースにおいてCIをまわすごとに異なる値を入力とする機構を仕込むことで、CIをまわせばまわすだけ、1つのテストケースでまわしただけの組み合わせにて入力値の確認ができる、という形です。 ここで、同値に区分されるべき値の中からランダムに要素を選ぶので、試験を失敗するということは実装を誤っているか、テスト（想定する振る舞い）を誤っているかのどちらかといえる可能性があり、それに気づくことができます。More
Appiumの不安定なところいくつか
Appium 0.16.0 がリリースされましたね！ さて、iOS/Androidともに動作確認しているのですが、いくつか出くわした現段階の不具合を備忘録かねて共有です。More
TurnipでAppiumを使ってみる
AppiumはRSpecでシナリオの記述が可能。さらにはCucumberも可能ということなので、ついでにTurnipでも実行可能なのか試してみました。 結果としては可能なのですが、以下、いくつか試したことをピックアップ。 試したときのファイル構成は以下の感じ。More
Appiumのスクリーンショット前にsleepする
Appiumのシナリオ書いてたときのメモ。 Appiumで提供されているスクリーンショット撮影時なんかは、スクリーンショット撮影コマンドの直後に別ページの遷移が入っていると、遷移アニメーション実行時にスクリーンショットが撮影されたりするのですよね。 そのときにsleepさせたいなと思って、seleniumやappiumのドキュメントを徘徊してたのですが、特にそれらしいAPIはなくどうしたものかなと思ってました。。 なのですが、単純に、rspecを書くときのsleepで問題なかったので備忘録もかねて。 これで、sleepの直前に以下のスクリーンショット用コマンドを入れておけば問題ないはず。 少しすっきり。More
Appiumの勉強会に使用した資料
過去作成した、Appiumに関する勉強会資料を記載。実際に作業を行う中でいくつか環境整備で問題が確認されたのですが、手元に置いておくだけなのはもったいないので。More
~ my tech diary ~ 