Tasting report portal again

Today, the reportportal pre-4.0 released.

I’ve posted try reportportal before and I thought the tool looks helpful for us. I know of Allure2 which is close to this tool but report portal is a more pluggable reporting tool.

The tool provides to analyze test results using ML technology. We can see the feature’s video from https://www.youtube.com/watch?v=d2ekWI2exZ4 and it looks interesting. I guess the feature will be a handly trial to analysis test resuts.

We can run the tool with docker-composer easily and also, we can add test data via demo data section. Read http://reportportal.io/docs/Project-configuration . Thus, we can see some dashboard to confirm the behaviour.

Also, we can handle data via API and the portal also provide LDAP authentication, but it’s beta yet.

Reporting and management bugs with scenarios help developers and the tool also considers automated test scenarios with some testing framework.


[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.

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.


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


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

[Erlang][Software Test]Property-based testing/QuickCheck Testing

I often see Property-based testing recently, and the following article is useful to understand what property-based testing and quick check testing is I’ve read for a few years.

PropEr Testing

I use QuickCheck testing in my work, and it works fine against functions especially stateless ones.

[Android][iOS]Awesome tips

Headless simulators

Appium(with WDA) can run headless simulators isHeadless against Xcode9+.
Awesome: https://github.com/appium/appium-xcuitest-driver/pull/472/files

composer, swarmer and mainframer

Replace Spoon for Espresso.

[Mobile]Security Testing tools

Classification Treeの歴史


[iOS]What’s new Testingを見た

What’s new Testingを見た。



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


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



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


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


  • 地味に嬉しい

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

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


[ReactNative][Test]Detox instead of Appium




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

“~ility testing”, not “no-functional testiong”

“~ility testing” is preferred than “non-functional testing” since “non-functional testing” indicate only others.

I agree with the opinion because “non-functional test” already have many kind of test.