Google製のFindBugsみたいなもののようです。 http://yone098.hatenablog.com/entry/2017/01/27/115753 https://github.com/google/error-prone これのパターンに何があるのかは以下に書かれていました。 http://errorprone.info/bugpatterns ざっと見てみると、DaggerなどのDIツールを使っている時のルールもありました。 独自ルールも追加できるみたいですね。 なので、何らかの自社製ライブラリへ適合させる時も使いやすいのかな。 Bazelを見ると、Bazelではすでにこれが組み込まれてて、デフォルトONなのですね。 https://github.com/bazelbuild/bazel/blob/c4e92b1ba06fba48121e4db8050a69b6d998e2e9/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/BazelJavaBuilder.java#L108 もう少し話がそれると、Bazelでは以下がデフォルトで組み込まれているのですね。 https://github.com/bazelbuild/bazel/blob/c51d506eb83f1e5974e3317c53532f6e81ca50d8/third_party/BUILD#L310 以下、試しに適用してみたコミットになります。 https://github.com/KazuCocoa/WebSocketDemoForAndroid/commit/806fe6cebef4e4c4435817b989fddf74724c55de これに対してビルドすると、generated codeに対してwarningが確認されました。 内容は http://errorprone.info/bugpattern/MissingOverride なのですが、ここら辺を見ているとGoogleのJava style gideに合致しているかも見ているのですね。More
Category Archives: software test
Architecture for GUI Testing(mobile)
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
「消極性デザイン宣言」を読んで、approchiabilityという言葉を知った
「消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。」を読みました。 シャイハック。 私自身、ここに書かれていたように消極的な人間で、V字タイプな人。少人数や大人数だとある程度大丈夫だけれど、微妙な人数になると「・・・」となるような。 そんな人たちのコミュニケーションの話から入り、だんだんとモチベーション、インタラクションの話へと内容が移ってきます。個人的に面白かったのは、approchiabilityという考え方と、モチベーションの話。ここのモチベーションはやる気を出していく話ではなく、やる気がわかないことを前提とした(意識の低い)モチベーションの話なので、疲れず良かったです。 人間は基本的には消極的 これが基本的な立ち位置でした。消極的なので、自然にできるようにどうデザインするかとか、そういう話になってきます。 機能があることではなく、”機能する”こと、その機能を使おうとしやすいことなど。 Usability と Approachability Usabilityは使いやすさとしてよく言われます。品質の話になるときや、人間工学の話、デザインの話といったように様々なところで出てきます。一方、Approachabilityという言葉は私が把握している限りでは初耳でした。 Usabilityとの対比としては、Usabilityが製品/サービスそのものの使いやすさを評価の対象とするのに対して、Approachiablityは対象となる製品/サービスがどれだけ”使おうとしやすいか”を評価しようとしている、という感じ。なので、製品/サービスのその周辺から連続した出来事を評価の対象に加えるという感じでしょうか。モバイル端末などの使いやすさとしてはこういった連続性に言及しているものもちらほら見ますが、そこに焦点を当てたものがこの”Approachiablity”という感覚を受けました。 使おうとしやすさ、行為の切り替え・接続、やめやすさ、いかに無理せず自然とできるか。 特別ではなく日常に溶け込む系のサービスとか製品ではこういう考え方って大事なデザインの話になりそうですね。 そういえば、インタラクションデザインにも言及していて、その中であったモチベーションの設計は色々なところで関係しそうな感じがしました。 締め こういう書籍は時折読みますが、Approchiabilityという言葉の定義はなかなか良い発見でした。More
[ReactNative][Appium]testIDの振られ方
ReactNativeだと、 testID としてiOSだとaccessibilityID、Androidだとview tagを使ってIDを埋め込むのですね。なので、ReactNativeのアプリに対してidで要素を検索したい場合はAndroidだと特に従来のAppiumやEspressoとは少し異なる。 Appiumだと、以下でview tagの取得をサポートするらしい。 https://github.com/appium/appium/issues/6025 これつくと、resource idが同じ要素も細かくidを振って操作することもできるようになるので、安定性向上に寄与しそうですね。 Does EarlGrey support finding react-native elements? https://github.com/google/EarlGrey/blob/master/docs/faq.md react native https://facebook.github.io/react-native/docs/accessibility.htmlMore
[UX]HEART Framework
GoogleのUXの話で、HEARTというフレームワークを見つけました。 http://www.appcues.com/blog/google-improves-user-experience-with-heart-framework/ この記事には、HEARTの中身である以下と、それぞれに対して実例を交えながらどういうものがそれぞれの要素に該当するのか、を説明しています。 name description how to measure Happiness: satisfaction, likelihood of recommendation / via user surveys User surveys Engagement: how much an average user is using your product (by time, sessions, etc) Analytics Adoption: the percent of users that adopt your product after signing up (user onboarding), and/or the percent of users that adopt…More
Read Advanced-Test-Automation-Engineer-Syllabus
ソフトウェアテスト/品質界隈だとISTQBやJSTQBは耳にする機会が比較的多いのではないでしょうか。 その中で、以下のようにadvances test automation engineerのシラバスが公開されていたので読んでみました。ジックリとではないのですが、流してどのようなことが書かれているのかをざっと。 http://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html 内容はテスト自動化の話をテストケースの話から実装時の設計の話、実行、レポートの話までと順に書いていました。実装時の設計のところらへんで、データ駆動とかキーワード駆動、プロセス駆動などの話があったりしました。 ざっと見た感じ、開発者からテスト側によっている人の方が読みやすい(想像しやすい)のかなーと思いました。More
[iOS]Run multi simulators with FBSimulatorControl
複数のシミュレータを1つの端末/OS上で起動可能な FBSimulatorControl はご存知の方も多いかもしれません。 それを使った時のメモ。最後の方に、XCTestを実行する時のものも。 installはリポジトリを参考に。 (以下は 0.2.0 のバージョン) listを表示 2つの端末を同時起動 help 以下のPR/議論で、結果の出力フォーマットとしてJUnitなんかを選択できるようになったようです。 formatterのサポート https://github.com/facebook/FBSimulatorControl/issues/281 https://github.com/facebook/FBSimulatorControl/pull/290 また、以下の通り .xctest を対象にすると、XCTestを実行可能なようです。 という形でテストを実行できる模様。 .xctest はAWS Device Farmとかでも使えるコレですね。 http://docs.aws.amazon.com/devicefarm/latest/developerguide/test-types-ios-xctest.htmlMore
[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
Appium1.6.0 released !!
https://github.com/appium/appium/releases/tag/v1.6.0 support XCUITest(WebDriverAgent) to test against Xcode8 x above iOS9.3 BTW, this feature has some unstable/known issues support UI Automator 2 for Android I already tried previous its beta version in my company, and then I issued some problems to Appium and it already fixed. I’ll switch to this new version from previous 1.5 in…More
read “The Way of the Web Tester”
The Way of the Web Tester を読んでみました。 私が読んだ時は、まだBeta3でした。最近、Beta4が出て、JSによるテストコードの話が追加されている状態でした。 この書籍は、自動化されたテストを書くための、テストエンジニア向けの入門書という感じです。内容はいかが大まかなところです。 Unit/Integration/UIのテストピラミッドの話 Unit/Integration/UIのテストコードの書き方(Rubyを例に) コラムとして、例えばrecord/playbackの使えないところ、など 全般的にWebだけの言及なので、モバイルに関しては対象外でした。Selenium系の書籍のようにツールに特筆してはいないので、そういう意味では確かに全般的な入門書という感じです。 ただ、コードの書き方などの話になるとリーダブルコードの内容や実装に近いところの話が含まれてきていたので、そこらへんの実装よりを詳しく学びたいとなったら何かWebフレームワークを使った実装とそのテストコードを書く、というところを開発者向けのなんらかの書籍など見て行う方が良いかもしれないです。 ある程度、書籍などで学んでいたり実装を経験した人からすると確かに入門的なものなのでザーッと読み飛ばしながらコラム中心に読んで終わり、となりそうです。More