In 2014, I talked about GUI testing architecture. 20141018 selenium appium_cookpad from Kazuaki Matsuo Recently, someone asks me about the architecture.So, I post the blog about it. The following flow means the architecture. I think this architecture is common if anyone uses libraries such as Cucmber. Scenario layer Describe scenarios. This layer depends on “User…More
Tag Archives: automation
[Appium]preventWDAAttachments for XCUITest strategy
Appium1.6.2から、 preventWDAAttachments というパラメータが付与されました。 これは、WebDriverAgentを動作させるときにXcodeのDerivedDataに多くの不要なファイルを書き込むことを抑制するために、そのディレクトリの権限を読み込み専用(555)に変更させるものみたいです。 defaultはtrueのようですね。 https://github.com/appium/appium-xcuitest-driver/blob/0c36c7659373c1c82a1411e50fa2503920909624/lib/desired-caps.js#L45 ただ、これはXcodeの権限設定を一部変更することになるので、capsには明記しておいたほうが良さそう。More
[Android]Reactive系のテストではIdlingResourceやっぱり大事
Rx系において、Android向けの物にはRxJavaの他にAgeraがあります。 codelabsにAgeraがきていたので、簡単な学びがてらやってみました。 Rx系のテスト(Espresso使ったUI含む)までも書かれていたので、Rx系学ぶ人には良い材料になると思います。やっぱりRx系のテストコード書こうとしたら、 Espresso.registerIdlingResources と IdlingResource の実装を使った非同期要素を待つ、ということがかけないといけないよなーということを思いました。 対象 codelabs https://codelabs.developers.google.com/codelabs/android-agera/ my repository https://github.com/KazuCocoa/agera-example-android Repositoryに対する処理 AgeraはRepositoryが1つの大事な要素だと書いていました。その中で、複雑なrepositoryを扱う場合は、以下のようになるそう。 https://codelabs.developers.google.com/codelabs/android-agera/#7 この中で、例えば値の変化を観測してそのないように変化があればそれをsetTextに反映する、というところは以下のようになる。 https://github.com/KazuCocoa/agera-example-android/commit/ba11829000bf820a2c34861cfb3e5c9b071a0e78 なるほど。 テストの書きやすさや保守も考えて… このようなAgeraの特徴の他、Rx系はcallback地獄のように入れ子にコードを書けやすいが、その反面そうするとテストしにくかったり保守が困難なコードが出来上がる。そこで、Ageraの例ではそこを対応する方法を紹介している。 https://codelabs.developers.google.com/codelabs/android-agera/#9 他、処理の分散としてメインスレッド外へ処理を逃がすために、 .goTo(mExecutor) を使った処理方法も。 Espressoも使う 最後、UI含んだテストとして、 IdlingResource の実装を使った Espresso.registerIdlingResources を利用した非同期型のこのようなRx系に対するテストコードも書いています。 https://codelabs.developers.google.com/codelabs/android-agera/#11 アニメーションOFFは毎度のご愛嬌ですね 🙂 最後に Reactive Programmingには幾つか世代があり、Ageraはまだまだ、RxJavaは2.0で世代3~4付近だと言われていました。 https://github.com/google/agera/issues/20#issuecomment-212007539 そうはいっても、Ageraを使ったこの題材は、Androidに対してReactive Programmingを入れてテスト書くまでをざっと学ぶことができるので、やることには良い意味があるものだなーと感じました。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
OSSとして公開された、巨大なFacebookのiOSアプリでUIAutomationを使うために使われているツール群
iOSアプリ開発、動作確認、テストを経験されている方なら分かるとおもいます。UIを確認したいときのiOSアプリの動作確認を自動化する時、UIAutomationを使う形が多いですね。そして、その場合において、一番のボトルネックはやはり実機やSimulatorの同時起動、実施速度の制約になっていきますよね。 UIAutomationは、実機で実施するには遅延があります。また、実機ではデータをCleanにして毎回テストを回すには、それ用のdebug機能を実装しなければ不可能です。 遅延に対しては、Facebookのinstruments-without-delayを経由して、遅延の少ないSimulatorで実施するこができていました。そして、特定のディレクトリを削除して毎回Cleanな状態を確保できていました。そういうことができるiOS Simulatorの価値は高いものです。(Xcode7ではツールの制約上この機能が正常に動作しませんが、このGistによると、Simulatorのplistをinjectionすれば有効にもできるそうな。) 例えば、Appiumはこのツールを組み込んでいるので、iOS実機もそうですが、シミュレータではより早く安定したGUI Testigを実施することができます。 なのですが、Simulatorは1つのセッションしか、Mac上では起動することができません。これはSimulatorやXcodeのinstrumentsに課せられた制約になります。 そこで、最近Facebookが以下の通りその問題を解決するようなライブラリをOSSとして公開しました。 FBSimulatorControl Objective-Cにより実装されていて、複数シミュレータを起動することができるようにしているもののようです。 以下がこのOSSのAboutなのですが、このライブラリは、Private APIの DVTFoundation や CoreSimulator にリンクして、直接ごにょごにょしているらしいです。例えば、シミュレータを直接操作する simctl を操作したり。Private APIをモリモリ使っているぽいので、Xcodeの変更に対してリスクはありますが、それでもFacebook同様、巨大なアプリはこういう形のツールを使わなければ、GUI Testingでは結構な時間を持っていかれますよね… About The original use-case for FBSimulatorControl was to boot Simulators to run End-to-End tests with WebDriverAgent. As FBSimulatorControl is a Mac OS X framework, it can be linked to from inside any Mac OS Library,…More
Appium1.4.0とruby_lib7.0.0がリリースされた
Appium1.4.0がBeta外れましたね。今回は、いくつかサポートに関わる気をつけておく内容がありましたのでめもめも。 Appium https://github.com/appium/appium/releases/tag/v1.4.0 いくつかにdeprecateがつきました Node 0.10サポート iOS6.1、iOS7.0サポート(1.5でサポート切るかも) Xcode6.3未満のXcodeサポート Xcode6.0.1+iOS8.0の組み合わせは例外 他は、BugfixやAndroid向けの新しいcapabilityの追加など。 ruby_lib https://github.com/appium/ruby_lib/blob/master/release_notes.md#v700-2015-05-08 わせて7.0.0がリリースされていましたね。本体と一緒にリリースする必要があるといってたので、miniWindowがnilになるときの対応が関係しているのかな。 default waitが0になった resourceIdのバリデーションが追加された install? メソッドが app_installed?にリネームされた rubocop対応More
Dagger2を使って依存性の存在する箇所をテストしてみた
Dagger2を味見してみた、Dependency Injectionに関して今更だけど学んだを経て、Dagger2を触ってみました。 簡単な、Injectionの機構を使って、依存関係のある場所をテスト時だけ異なる依存関係にしてテストを実施する、というところまで達成できました。よかったよかった。そして、ある程度理解できたので、あとは実際の実装に落とし込みながらなじませる、が必要そう。 確認した内容はごくごく簡単で、表示する文言をビルド環境によって変更するというもの。Dagger2では、injectionするために@Moduleのアノテーション、@Providerのアノテーションつけられたものに対して以下のようにModuleをセットします。そこで、 SampleTestModule のように依存関係を拡張したModuleを渡してあげれば良いだけ。 Dagger2はコンパイル時に依存性が注入されるので、コンパイルされるまでは DaggerSampleApplication_SampleApplicationComponent に警告が表示されますが、それは気にしない。 通常 依存性注入 トラブルシューティング 以下の2点、気をつける必要があった。 compileOptionの追加 Gradleプロジェクトでは以下を追加しましょう。 annotationライブラリの追加 Gradleプロジェクトでは以下を追加しましょう。 ref: http://stackoverflow.com/questions/25090570/google-auto-factory-not-annotated-with-provided その他 終わったあとに見てみたのだが、以下記事も参考になりそう。 http://www.future-processing.pl/blog/android-testing-with-espresso-2-and-dagger-2-mocking-long-running-operations/ ButterKifeとDagger2は触って感覚を覚えたので、今度はRoboGuiceかな。 testotips.ioで、依存性を持つところのテストTipsとか共有したい機運だ。More
Dagger2を味見してみた
Dependency Injectionの、Dagger1とDagger2を学んで、DIの理解を深めてみる。Tasting Dagger 2 on Androidを参考にしました。 Dagger1はGuiceに影響を受けている。特徴は以下。Compile time injection。 Multiple injection points: dependencies, being injected. Multiple bindings: dependencies, being provided. Multiple modules: a collection of bindings that implement a feature. Multiple object graphs: a collection of modules that implement a scope. Dagger2はAutoValue projectの影響を受けているらしい。 No reflection at all: graph validation, configurations and preconditions at compile time.…More
Dependency Injectionに関して今更だけど学んだ
最近、Android開発でテストを構築していくとき、Dependency Injectionは避けて通れないものだなと感じたので、DIを頭になじませるために本腰を入れて学んでみることにしました。 DIの概念や簡単な説明自体は少しWebを探せば見つかるのですが、それが頭に馴染むのには少し時間がかかった… あと、実装コードをもう少し手を動かさないとな、という感じです。 作って学ぶ Dependency Injection [Ruby][設計] Jim Weirich さんから学ぶ DI(Dependency Injection) When to use Dependency Injection Inversion of Control コンテナと Dependency Injection パターン 原書: Inversion of Control Containers and the Dependency Injection pattern objc.ioの記事から Dependency Injection, Annotations, and why Java is Better Than you Think it is Injectionの機構を組み込むとき、大きくわけて Compile Time と Runtime Annotation…More
koboldを使い画像を比較する
画像比較ツールは数多くありますが、少し前にkoboldを使ったのでそのメモです。 kobold koboldは、perceptualdiffのような画像比較をnodeで行うことができるツールです。nodeで実施できるので、npmで管理することができる点、ほかツールとの組み合わせが容易なところが良いなと思ったところです。 ImaeMagicやperceptualdiffをコマンドラインから使う、ということは前からしていましたが、Yahoo!が公開しているkoboldがいい感じにnodeで切り出していたものを少し前に見つけました。機能が限定されているために不要な処理がなく使い易いです。 このkoboldの画像比較のコアはblink-diffのようです。なので、細かな設定値に関してもblink-diffをみるように書いています。blink-diffを個別に使う、でも良いかもしれませんね。 サンプルコード 以下GitHubのREADMEの通りにやれば、ざっとできることを想像できます。 https://github.com/KazuCocoa/sampleKobold positive 全体の設定のほかに、特定ファイルだけに適用したい個別の設定を追加することができたりと、比較的自由がきく npmで管理できる blockOut オプションにより、特定の領域を比較対象外にすることができる negative png以外にも比較を行いたい場合、これではまかなえない 結果の出力が今は標準出力だけれど、欲しい形で少し整形したいな。More
~ my tech diary ~ 