別用もあって、XCUITestをちゃんと触ってみました。 XCUITestに対して多くのプロジェクトで問題になるのって、多分既存コードに組み込むことができるか?だと思うのですよね。(私もそうです) なので、iOS6.0をdeploy targetにしているAppiumのサンプルコードを引っ張ってきて、それを7.0にあげた状態で動くか、というところから確認してみました。結果的に、アプリは7.0を保ちつつ、XCUITestはiOS9.0を対象にしてテストを回す、ということができました。Xcode8頃から怪しくなりそうな気がしているInstruments越しのUIAutomationを見ると、できるところからiOS9系だけでもXCUITestを視野に入れ始めたほうがよさそうですね。 修正したコードは以下に入れています。 git clone して、iOS9シミュレータをターゲットに設定して command + u で実行できます。 https://github.com/KazuCocoa/XCUITestExample/tree/master やったことは、 サンプルコードを取得する iOS7.0をミニマムにする XCUItestのターゲットを追加する 幾つかのテストコード書く(ついでに、accessibility付与したり、要素の結合したり) https://github.com/KazuCocoa/XCUITestExample/blob/master/TestAppUITests/TestAppUITests.swift accessibilityIdentifier や title、private methodへの切り出し くらいです。 そのほか Storyboardから、 accessibilityIdentifier を設定できるようになっていました。Storyboard中心になるのは、実装とUIを切り分けできているので良いのではないかなと思います。 ただ、動的に変化する要素に対してaccessibilityIdentifierを付与する、というのはやっぱりコード読み書き必要だし、テストコードはやっぱりSwift/Objective-Cになるだろうので、中身見ることができる人は必要、というのは変わらなくて良いのですけどね。 XCWaitCompletionHandler がwaitとしてつかえそうだったりと、Instruments越しのUIAutomationよりは、個人的に安定した並列実行とかもできるのでは?と少し期待。 これの成果物、Amazon Device Farmなんかにも適用できるかなー。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review,…More
Category Archives: software test
[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
[Elixir]power_assert_exをex_parameterizedと組み合わせて使ってみた
Power AssertのElixir版を、 @ma2ge さんが作成されていたので、ex_parameterizedと合わせてみました。ex_parameterizedは、パラメータ化テストの記述を支援する、簡単なマクロです。 power_assert_ex https://github.com/ma2gedev/power_assert_ex ex_parametarized https://github.com/KazuCocoa/ex_parameterized やることは簡単。単に、 use ExUnit.Case を use PowerAssert に置き換えるだけでした。 ex_parameterized自体、単に test マクロを内部では使っているだけなので、特に変なAST操作は行っていません。なので、問題なく表示されました。すごい。 以下は、ex_parameterizedのテストをわざと失敗させた時の出力結果です。 まだ色々と制限もありますし、ExUnitの結果自体そんなに読みにくいテスト結果なわけではありません。ただ、なんだかんだでテスト結果を観察することが楽になりますので、良いなーと思いました。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