Category Archives: test automation

WerckerでAndroidアプリをビルドしてみた

前回のTravisに続き、Wercker★, ★でAndroidアプリをビルドしてみた。ビルド対象のアプリは同じものを使用。Werkerに登録を行い Add and applicationを選択すると、GitHub Repositoryの登録から、ビルドスクリプトの作成、実施までトントン進んだ。ざっと、作業自体10分程度で終わったのだけれど、以下に作業内容をつらつらと書く。 WerckerにはBoxとかもろもろの概念があるのですが、ここではそこら編はここでは言及していないです。 リポジトリの登録〜成果物ができるまで、後少し他を書いたくらいの内容です。More

Travis CIを使ってAndroidビルドを試してみた

CI環境をいくつか比較してみようと思います。 主な対象はモバイルアプリのビルド環境なのですが、まずはTravis CIから。 対象はAndroidです。 記載内容は、基本的には公式ドキュメントを参考にしています。 ほぼ、Androidについてくるサンプルプロジェクトと同じようなレベルのものを使用しています。More

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

Appium1.0.0(Orion)とruby_libを使ってみる

Appium 1.0.0 がリリースされていましたね。Orionという名前っぽい。 これからruby_libなどのライブラリがappium側の正式サポートとして整備されていくわけですが、0.18.x系から1.0.0系はappiumとしての機能が追加されていく、と開発者の方はGithub上でちょくちょくいっています。そこで、0.18.x系と1.0.x系で変わったところの確認と、ruby_libを軽く使ってみての内容を以下に書いてみます。More

Appiumを使ってRSpecの記述とTurnipの記述とで、結局はどちらが受け入れとして使えそうか

比較的、ぱっと見て操作を想像できることが受け入れ試験では大事だと思います。 そう考えると、RSpecはshared_exampleなんかで操作をまとめることができるのですが、Turnip/Cucumber形式のシナリオアウトラインを使った方が綺麗にかけそう。 一方、capybaraのように、RSpecの拡張としてFeature specを使うこともできる形があります。なら、Appiumを使って同様に受け入れ試験の形を模倣するならば、CapybaraのFeature specを参考に類似した記述を模倣すれば、RSpecのみである程度読みやすい受け入れ試験もかけるかもと思い、以下をまとめてみた。More

TurnipでScenario Outline

Turnip+Appiumで使ってキーワード駆動のシナリオテストが実施できそうね “Turnip or RSpec” x Appium 受け入れ試験レベルの抽象度のシナリオを、Appium x “RSpec or Turnip”で比較してみた TurnipでAppiumを使ってみる とAppiumとTurnipを使ってみたけれど、Turnipでscenario outlinesかけることが確認できたので、私の中でようやっとこの方向性が一段落しそう。 あとは、RSpecのshared_exampleの記述と少し比較してみて、という作業もいるけれど。More