XCUITestでは、自動的にスクリーンショットを取得してくれます。それがどこに保存されるか?というと、以下のように Attachments に保存されました。保存されるファイル名に統一感がないのですが、 plist にテストケースとスクショの結びつけを保存しているのですね。テスト結果をXcode以外からうまいこと見ることできないかなーと思ってたのですが、すんなりホイとはできなさそうな感じです。 /Users/user-name/Library/Developer/Xcode/DerivedData/TestProject-randome-values/Logs/Test/Attachments あと、スクショのタイミングを任意なタイミングではできないので画像比較のためにそれを使う、というのには使えなさそうな感じです。んー。テスト失敗した時の参考になる以上ではちょっと使いにくい感じです。 ついでに、XCUITestでも、カバレッジを取得できる模様?ちゃんと計測はしていないのですが、うまいこと使えれば使えそうでした。 そのほか XCUITest、いろいろ調べてみましたが通知のダイアログなどのシステム設定をリセットする手段ないので、ちょっとテストケースの管理に難しさを感じました。 ちなみに、wait/sleepは適度にwaitしてくれるので、さほど気にしすぎなくても良いのですね。 waitUntil のようなメソッドを定義したのですが、それを使うのは限定的になりそう。retryが内包されているのはGUIから操作するテストケースではありですね。Exceptionを出す種類も、 XCTAssert 系以外にもいくつかあったのですが、ここはXCTestの頃からそのまま使っているもののようですね。 このfastlaneのsnapshotも、このXcode7(XCUITest)対応したみたいですね。 https://github.com/fastlane/snapshotMore
Tag Archives: test
[iOS][Swift]XCTestでパフォーマンスを計測したり、処理をwaitする
XCUITestでテストを行う時、アニメーションの都合で処理をまったり、突然の性能劣化がないか、ということを計測することの重要性が高くなります。 そこで、XCTestを使ってそれらを実現する方法を最近調べたのでメモ。 処理性能を計測する ある範囲の処理の処理性能を計測したい場合があります。 XCTestでは、以下の通り measureMetrics を使って、与えたブロック内の処理を計測、一定の性能劣化があった場合にfailしてくれる機能があります。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters func testShouldDisplayAlertWithText(){ // run 10 times and…More
[Android]Amazon Device FarmをInstrumentsのテスト/APIからの操作で試してみた
Amazon Device Farmに関して、実際に色々触ってみての感想。 既存のinstrumentsのテストやEspressoを実施、はたまたAPI経由で操作した時の感想です。(APIはできる、ところまで確認したというのが正しいですが。時間あったらAPIは試す。) 即時性の求められるテスト実行には少し向かないけれど、案外段階かもしれない。 Androidのinstrumentsによるテストの実施 JUni4の記述を自動でテスト対象と認識させるには以下が必要。JUnit4ベースになって test の接頭辞をつけなくなって良かったのだけれど、ここに来て必要になるとは… テストクラス名に*Testと、Testの接尾辞をつける テストクラス内のテストケース名にtest*と接頭辞をつける 他は特に問題なさそう。 @RunWith(Theories.class) と @DataPoints におけるパラメータ化テストだったり、 @Before/@Afterはともにできました。また、Espressoのテストも無事実施することができました。 この28件の成功の中には、EspressoやParametarized Testも含まれている状態です。 参考: https://github.com/awslabs/aws-device-farm-sample-app-for-android/issues/5 https://forums.aws.amazon.com/thread.jspa?threadID=211353&tstart=0&messageID=669228#669228 アップデートするAPKの生成 $ ./gradlew assembleDebug $ ./gradlew assembleDebugAndroidTest APIによるアップデート、テスト実施の自動化 AmazonのRubyライブラリにすでに統合されていた。 https://github.com/aws/aws-sdk-ruby なので、特に問題なくテスト対象のapkをアップロード、instrumentsのテストを実施、結果を得るという一連の流れをRubyスクリプトでサクッと実現できそうでした。 ドキュメントはこちら。中身見ると、JSONで設定ファイル作れば十分な感じがしますね。 http://docs.aws.amazon.com/sdkforruby/api/Aws/DeviceFarm/Client.html 重要なところは、 #create_upload(options = {}) ここで、テストのconfiguration設定時には type: に INSTRUMENTATION_TEST_PACKAGE を指定する #schedule_run(options = {}) 実際にテストを実施する ほか、いくつか端末の設定も含まれているのでいくつか通信が必要そう。 締め 色々段階っぽいですが、現状の結論としては以下ぽい。 (私のコメント箇所は、最終的にクラス名にTest加えたり、テスト対象だけtestつけるとかしたら解決できました。) @Kazu_cocoa 手元でも動かせるテストをリモートでも自然に動かせるみたいのじゃないとテスト書くのやってらんないし、現状特定用途向けにしか使えなそうっすねえ。デベロップメントテスト走らせるには厳しい —…More
[Java]最大値の反転で負の数値になってた(初歩的なミス…)
Javaの、基本的なところで見逃してしまった不具合を、自戒を込めてメモ… キャストの順序により、補数によって負の数値として扱われていたのか… long で宣言されていた time を計算で使っているので、括弧内の計算も long で計算されるとなんか脳内変換していた…テストする人として、見逃してはいけないような初歩的なミスだ… ※DateUtils使えば、とかの話は置いておいて… This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters import java.lang.Long; import java.lang.System; import…More
駆け足でテストコードのプラクティスを学べる『実践JUnit』を読んだ
いざアサートせよ 緑の光あれ 我ら Javaの騎士 少し前に『実践JUnit』の書籍が発売されました。 対象とする読者に書かれているよう、ユニットテストの記述に慣れていない人を対象にしているものです。ツールの詳細などにはあまり踏み込みませんが、 どのようなテストが良いとされるのか というプラクティスや考え方がまとまっています。 ユニットテストフレームワークは随分使われてきました。その中で蓄積されたプラクティスを知って取り組むのと、知らずに取り組むのでは考え方の洗練されかたに差がでますよね。きっと。 この考え方は開発者テストと言われるユニットテスト以外にも、統合であったりシステムであったり、様々なスコープのテストコードを考える上でも共通して使えるものです。なので、 具体的なツールはある程度知っているけれど、どのような粒度、もしくは内容を意識してテストコード書けば良いか、そもそもの指標もわからない という人はかなり適したものな気がします。 私個人は、どのようなテストが良いのか?といったポイントは見聞きしたことがあるものでした。ただ、JUnit4 + Hamcrestの組み合わせのフレームワークの使い方には疎かったので、ツール自体は知っていましたがそれらを使ったフレームワークの遷移が面白かったです。他、テストのリファクタリングの テストの臭い は面白かったです。TDDであったり、 活きたドキュメントとしてのテストコード まで言及されていたのはさすがでした。 いくつかかいつまんで… 良いテスト FIRST Fast Isolate Repeatable Self-Validating Timely テスト対象 Right-BICEP Right Boundary Inverse Cross-check Error Performance 境界条件 CORRECT Conformance Ordering Range Reference Existence Cardinality Time テストの臭い 不具合ありそうなコードの臭いみたいなのと同じで、よくなさそうなテストコードの臭いです。 不必要なコード アブストラクションの欠如 無関係な情報 肥大化したコンストラクタ 複数のアサーション 不必要な詳細さ 誤解を招く構成 暗黙の位置付け ここら辺で言われているのはテストコードに限った話ではないですね。…More
やっぱりモバイルアプリの(シナリオベースの)テストコードは1つの言語で書きたい
ruby_libのissueでとある文言を見て、そうだよなーと感じたもの。 https://github.com/appium/ruby_lib/issues/337#issuecomment-143345864 Originally we used Ruby across web/ios/android. The mobile tests weren’t stable. Now we have 3 suites in different languages. – Ruby web test suite (angular_automation) – Java Android suite (Espresso) – Objective C iOS suite (XCTest) It’s a lot of work but the tests are stable and fast. I hope the new mobile…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
AndroidTestingSupportLibrary22.2.1リリースメモ
2015年9月14日に、新しいAndroid Testing Support Libraryがリリースされていました。Android Test KitのEspressoなどのバージョンがあがってたのでざっと調べたに続いて、少し見てみようと思います。 releasenoteなんかはgithub.ioで公開されるようになったのですね。 https://google.github.io/android-testing-support-library/downloads/release-notes/index.html リポジトリはこちら https://github.com/google/android-testing-support-library/tree/gh-pages 主な内容 espresso 各種修正 rule IntentTestRule の追加 runner JaCoCo supportの修正 test shardingの修正 他、API 23に向けた修正 External contributionという枠があったのですが、外部からの修正に関しても明記するようになったのですかね。貢献へのモチベーション上がりそうな感じですね 🙂 One More Things GitHubにAccessibilityの確認用ライブラリが公開されていました。Espressoの、Accessibilityの部分ぽいです。 https://github.com/google/Accessibility-Test-Framework-for-Android/blob/master/src/main/java/com/google/android/apps/common/testing/accessibility/framework/integrations/espresso/AccessibilityValidator.javaMore
『ソフトウェア・テストの技法 第2版』を久しぶりに読んだ
『ソフトウェア・テストの技法 第2版』 を再度読んでみました。 読み直す、と積読にしてたもの。 入門的なものなので、結構前に読んでいたのですが、改めて軽く読んでみました。ソフトウェアテストであったり、デバッグであったり。プログラムを書く上で、エラーを見つけて治す、というところに対する原理原則をまとめている書籍です。 用語の定義は置いておいて、昨今の開発者テストの文脈で開発者も多少は目を通すのも良いかなと思った内容です。 ソフトウェアテストの心理学 テストとは、エラーをみつけるつもりでプログラムを実装する過程である。 (この書籍における)ソフトウェア・テストの原則 テスト・ケースの必須条件は、予測される出力または結果を定義しておくことである プログラマは自分自身のプログラムをテストしてはならない プログラム開発グループは、自分達のプログラムをテストしてはならない それぞれのテストの結果を完全に調査せよ テスト・ケースは、予想できる正しい入力条件ばかりでなく、予想しないあやまった場合も考えて書かなければならない プログラムを調べるのに、それが意図されたように動くかどうかを見ただけでは、なかば成功したにすぎない。残りの半分は、意図されなかった動きをするかどうかを調べることである プログラムが本当に使い捨てのものでないかぎり、そのテスト・ケースも使い捨てにしてはならない エラーはみつかれないだろうという仮定のもとにテストの計画をたててはならない プログラムのある部分でエラーがまだ存在している確率は、既にその部分で見つかったエラーの数に比例する テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である そういえば、エクスロリームプログラムにおけるテストであったり、インターネットを含んだWebアプリのテストの話が載ってました。2版で追加されたものですね。 前者は、JUnitなどのフレームワークも用いた、自動化されたテスト群をおもに扱っていました。後者は、ネットワーク含むシステム全体を、ネットワーク/DB/Webアプリのモデル層などのように区分して、それらに関わるテストの話を載せていました。 Webアプリのテストの話では、コンテンツ・テストとしてGUIに関する要素が、利用時の品質に大きく関わる、という文書がありました。おもに回帰テストにおけるテストの実行速度の面になるとどうしても優先度下げられたり、人海戦術任せになってるところがありますが、ここら辺は利用時の品質に大きく関わる(利用者が多ければ、尚更)箇所なので、ちゃんと言及されているのは良いことですね。 システム全体の構成の話、目新しさは無かったのですがそこらへんの要素を経験/学んでいない場合は目新しさに映るのですかね?昨今ではそれぞれの箇所で専門性が高まったり、よくあるSeleniumを使ったE2E系の話しだとそれらの多くの要素が(意図的かどうかは置いておて)省略されている場合もあって、システム全体に対する構成に対する想像がされない世界になってきている気がします。 隠蔽された良い面と、開発やテストを行う者としては知らなさがシステムを造る上では悪い面がありますね。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