[Swift] Identify not XCTest against XCUITest and EarlGrey

XCTestでは、Swiftの時にAppDelegateを取得しようとするとクラッシュする問題があります。
そのために、

XCTAssert(NSClassFromString("XCTest") != nil)
XCTAssert(NSClassFromString("XCTestCase") != nil)
XCTAssert(ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] != nil)

などを使い、XCTestである場合はmockしたAppDelegateを使うなどの対策を行うことがあります。ただ、この場合だと、 XCUITestEarlGrey によるテストを行うときもこの判定に引っかかります。

以下の差分には、XCUITestとEarlGreyに置ける上記判定を入れています。両方とも同様に判定が行われます。

https://github.com/KazuCocoa/test.examples/commit/cd3ec48b741320071471b27b3ad6254ce4fbacd5

これを避けるために、例えば環境変数でEarlGreyであることを指定する、などが必要。

XCTAssert(ProcessInfo.processInfo.environment["EarlGrey"] == "true")

https://github.com/KazuCocoa/test.examples/commit/aa527223208d4d56260fa0111ccf158554c0d12f

プロセスに対する環境変数、iOSのテストだとちょくちょくお世話になることがあると思うので、覚えておくと良さそう。xcodebuildなどに対して環境変数を与えると同じようなことになりますが、これはプロセスに対する環境変数なので注意が必要(プロセス外で定義した環境変数は参照されない)

Advertisements

“初めての自動テスト”は様々な人に手にとって読んでほしいものだった

9月21日に発売された”初めての自動テスト ―Webシステムのための自動テスト基礎”を恵贈いただいたことと、少しレビューさせて頂きましたので合わせてこの書籍に関して書こうと思います。(以下、本書)

この本は元々、The Pragmatic Bookshelfでβ販売から開始されたThe Way Of The Web Testerが玉川さんによって翻訳されたものです。この書籍の著者は、アジャイルサムライを書かれたJonathan Rasmussonさん。

私はβ配信の頃にこの書籍を見つけ、過去、このBlogにおいても簡単な感想を書きました。その頃から少し後半が更新、少し内容が追加され、2017年6月29日に最新版が配布されました。本書はその最新版を翻訳したものですので、その内容は最新のThe Way Of The Web Testerと同等のものとなっています!

私は、玉川さんととある活動で知り合っていたこともあり、本書の翻訳レビューと主にはRubyコードに関わるところで相談させていただきました。また、過去にこの書籍の原書を読んで内容の素晴らしさを感じていたので、レビューの相談を頂いたさいも良い意味でとても驚きました。レビュー時から感じていたのですが、この翻訳版である本書の表現などの素晴らしさは玉川さんのご尽力のおかげです。とても良い仕上がりになっているかと思います。

本書に軽く触れる前に、私がこの書籍で好きなところを残しておきます。本書は、開発プロセスなどのテストに関わる周辺環境をなるべく剥がし、テストやそのコードに関わるところの足場に注力しているところです。一方で、ただ単にテストコードの話だけに止めるのではなく、そこに至るまでの話を チーム を中心にしているところが気に入っています。そのため、英語版、日本語版共に、これからテストに入門する人、経験の少ない人、経験の深い人各々に、それぞれの良さをつけてオススメしたいと思っています。

ここで少し話を脱線すると、本書に書かれているレガシーコードに対するUIテストの導入話や、テストピラミッドの話は、少し前にtry!Swiftにてお話させて頂きました内容と同じようなことも言っています。そのため、本書はWebと題しながらも、モバイルなどにも汎用的に使える考え方も多いことを感じるでしょう。

では、少し本書に触れます。

チームの人に

第1章、第8章は概念、実際にテストを導入するときに気にしないといけないところを中心に書いています。そのため、広くチーム全員にオススメします。この箇所で共通認識を持っていると、導入するテストの全体像に対する共通認識を説得する手間が省けるとおもます。読書会みたいな感じで話し合うのも良いかもしれません。また、ここではプロダクトに対するテストの全体像、どんなテストを、どのくらいの量、自動化すると有用かということを知るもとができます。

コード書く経験があまりない人に/手動テストが主な人に

8章までは基礎的なことが書かれているため、そこでテストコードの実装含め、基礎を学ぶことができます。実際にコード書きながら様々なユニットテストを学んだり、Webアプリの仕組みを大まかに学ぶことがでるためです。ここを学ぶと、発展的な内容を学ぶ土台となる知識が得られ、プログラミングが関わるような勉強会でもある程度話が想像できるようになると思います。

9章以降ではもう少しちゃんとプログラミングに触れたり、より良いテストコードの書き方、テストファーストの考え方まで学ぶことができます。本書にも書いてますが、本書をざっと学び、コードを書きながら経験を積んだ後には、よりテストコードを書き、よりコードを書く経験を増やし、他の書籍などを読みながら自分の力で自動テスト関係やその周辺環境の経験を増やしていけるでしょう。

本書を読み終えたら

プログラミング言語でいうとここではRubyを題材にしていますが、モバイルに足を踏み入れるとJavaやKotlin、Objective-CやSwiftに触れる必要が出てくるでしょう。また、Webでも他の言語を学ぶことができます。言語におけるテストコードの文化や書きやすさの違い、プラットフォームによるテストし易さの違いを学びながら、より発展的なエンジニアとしての道を歩むことができるでしょう。

よりテスト技術に関して学びたい場合は、テスト技法関連の書籍を追ったり、GitHubなど含めてモックライブラリなどのライブラリを追うと良いでしょう。様々な、それぞれ使用感の異なる多様なライブラリに出会い、それぞれの良し悪しを学んだりできるかと思います。

また、ここの学んだことをベースに、アジャイルテスターのような方面に足を踏み入れることも挑戦的で面白いかと思います。開発プロセスなどが絡む方面に進むこともまた面白いかもしれません。

いずれにせよ、本書は様々な経験をする足場を学ぶことができるので、ぜひ手を取ってみていただければと思います。

[Android]Run orchestrator 1.0.0

Download apks from maven:

And install them and start the process like https://developer.android.com/training/testing/junit-runner.html

adb install -r path/to/orchestrator-1.0.0.apk
adb install -r path/to/test-services-1.0.0.apk

# Replace "com.example.test" with the name of the package containing your tests.
adb shell 'CLASSPATH=$(pm path android.support.test.services) app_process / \
  android.support.test.services.shellexecutor.ShellMain am instrument -w -e \
  targetInstrumentation com.example.test/android.support.test.runner.AndroidJUnitRunner \
  android.support.test.orchestrator/.AndroidTestOrchestrator'

If you have a custom runner, you can replace android.support.test.runner.AndroidJUnitRunner to yours.

After the above, you can start instrumentation tests via the orchestration layer.

./gradlew connectedAndroidTest

[Android]composer and swarmer

I’ve posted [Android][iOS]Awesome tips about composer and swarmer.

The following is my trial with them.

https://github.com/KazuCocoa/run_parallel_tests_android

[Android]Checking Android Testing Support Library 1.0

update: Aug 9, 2017

I encountered no tests found error when running tests with AssertJ and AndroidJUnitRunner1.0.0.
https://stackoverflow.com/questions/45402645/instrumented-tests-failure-with-androidjunitrunner-1-0-0-and-assertj


A few days ago, Android Testing Support Library 1.0 was released.
I pick up some awesome stuff for me, and I think this release will help enhance test automation for other 3rd party libraries.

IdelingResources

help synchronise against

  • Executors
    • com.android.support.test.espresso.idling:idling-concurrent:3.0.0
  • network requests and responses
    • com.android.support.test.espresso.idling:idling-net:3.0.0

New view matchers/actions/methods

Parameterised testing

GrantPermissionRule

Understand how to write/think test for Android

Android Test Orchestrator

Runner related command options

  • -e classLoader – Provide the ability to pass class loaders using runner args
  • -e filter – Add support for custom JUnit filters to be specified using runner args
  • -e runnerBuilder – Allows developers to provide their own implementations of RunnerBuilder that can determine whether and how they can run against a specific class

[iOS]Large Photo Libraries for Testing

from https://developer.apple.com/videos/play/wwdc2017/505/

If you’d like to test with a large number of photos, you can generate dummy photos by https://developer.apple.com/sample-code/wwdc/2017/Creating-Large-Photo-Libraries-for-Testing.zip . Download it and run on the target device.

The app is presented in https://developer.apple.com/videos/play/wwdc2017/505/ .

https://developer.apple.com/documentation/photos/phasset

[iOS]What’s new Testingを見た

What’s new Testingを見た。

https://developer.apple.com/videos/play/wwdc2017/409/

見ている途中でいくつかメモしたので、その記録として…


  • multiple appのテスト、URLを引数で与えることできるのね

20170612035154_img20170612-17-2kk0z7_480

  • Accessibility Dataのところで説明しているsnapshot、WebDriverAgentが使っているやつぽいな
  • おー。いちいちsnapshot取得する必要がなくなるのか。実行時間改善しそう

20170612035308_img20170612-16-1ng7xs0_720

20170612035501_img20170612-14-zvr8i3_720

  • 要素の検索で全捜査でなくて最初にマッチしたものだけさっと返すようにした、という話だけれど、ようやくという感じ。

20170612035637_img20170612-14-nebl01_480

  • ここら辺は元からそうなのでそうよねという感じだ。
  • ここはどこまで厳密に書くかはどれだけ内部実装と結合を強くするかの問題ですね。Espressoでも同じ問題をもつ。

20170612040244_img20170612-19-18xc35w_720

  • 地味に嬉しい

  • Activity styleの書き方、Cucmberとかイメージすると良さそう。stepsにいろんな処理を入れて、シナリオはstepsを並べて記述するような感じが使い方として近そうだ。

  • 非同期の奴も良さそう。XCTestなので、XCUITestでも使えるし。
  • snapshotのところはほんといろんな3rd partyも恩恵受けるだろうし、良いことづくしな気がする。けれど、これはXcode8でないと使えないOSテストするときは恩恵受けられないので、完全に恩恵を教授できるのは数年後かな…

Xcode9のいくつかの機能、Xcode9以前でも使えると恩恵大きくて良いな…

[ReactNative][Test]Detox instead of Appium

2017/06/08現在

過去、ReactNativeに対するUITestに関して書いていたのですが、今の段階ではAppiumよりはDetoxを使うほうが、JSを経由したテストツールとしては良さそう

EarlGreyも参考にしている所とかあり、より安定したUIテストを実施するには現実的な気がします。
Androidのサポートも計画されているので、必要に応じてコミットしたいですね。

参考: [ReactNative][Appium]testIDの振られ方

Netflixの複雑なマイクロサービスに対するテスト自動化

とても面白い。

Netflixの、マイクロサービス環境下におけるテストの複雑さを解決しようと取り組んでいたことの内容と、その1年の成果が書かれている。

here

読んでいてもとても面白く、テストエンジニアという立場からすると純粋にとても挑戦的に面白い内容だと思った。

また、社内の利用をより簡単に、利用者に負担をかけない取り組みも良いですね。
カッコ良い。

[iOS][EarlGrey]Run tests quickly

Small, small tips to enhance conducting speed for EarlGrey.
In many cases, iOS can’t handle animation speed such as Android even UI Test cases.

EarlGrey available changing animation speed except for UIScrollView. here

// Swift
let kMaxAnimationInterval: CFTimeInterval = 5.0
GREYConfiguration.sharedInstance().setValue(kMaxAnimationInterval, forConfigKey: kGREYConfigKeyCALayerMaxAnimationDuration)

// Swift
GREYTestHelper.enableFastAnimation()

https://github.com/google/EarlGrey/blob/master/docs/faq.md

In XCUITest case:

# swift
UIApplication.sharedApplication.keyWindow.layer.speed = 100