[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
http://propertesting.com/

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

Advertisements

Classification Treeの歴史

知らなかったので、メモ

[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以前でも使えると恩恵大きくて良いな…

“~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.

Watch “Test-Driven Development on Android with the Android Testing Support Library”

pick and past some key images to the following.

  • A famous test pyramid

20170519024718_img20170519-17-x25i39_720

  • Development Lifecycle for UI Component

20170519025016_img20170519-11-107pbac_720

  • Development Lifecycle for non-UI, especially unit level, Component

20170519025038_img20170519-17-1lny2qd_480

  • Robolectric

20170519030006_img20170519-14-1lgebza_720

  • Espresso’s lifecycle

20170519031440_img20170519-17-wz5rvd_480

  • Boundaries between M level and L level

20170519031901_img20170519-17-hireh1_720

Previously, I’ve published blog for test strategy for mobile.
This video is similar to the article 🙂

ICST2017メモ

ICST2017に参加して、会社のBlogには以下の通り少し書いたのだけれどGistに残したメモをGistのままにしておくのはもったいなかったのでメモがてら。

techlife.cookpad.com/entry/2017/04/04/180000

[design]inclusive design(My 4th day)

This post is memos for 30 days of accessibility testing.

https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

4th day’s mission is researching inclusive design. So, I attach some articles in this post.

[Swift]try!Swiftで学んだことまとめ

私は職場で作ってきたテストの話のうち、UI Testに近いところの話をしました。

英語での発表は初めてだったのですが、一部想定通りに話せなかったところがありながらも無事に終えることができ、ホットしました。日本以外から来た人含め、いろんな人から英語も聞き取りやすかったし内容も良かったと言って貰えて、ひとまず安心しました。

お題の悩み

私はSwiftを使ったテストの話(Unit Test)をするかとか、protocolベースのDIの話をテストに絡めるか、UI Testの話をするか悩んでいました。

推薦されたことで話すことができるようになったので、try!Swift全体の中でそれぞれの話す内容が重ならない程度の話題にした方がバリエーション豊かになって良いかなと思い、UI Testsやその周辺の話をしました。

ただ、このレイヤの話はSwift自体でそこの話をするにはネタがない。XCUITestとかだとSwiftではなくiOSフレームワークの話になりますしね。半端にSwift x XCUITest(内部コードとか)の話をするよりは、テスト全体とUI Tests、Re-Engineeringnの話をする方が独自性を持った話ができるかと思い、結果的には話すことにしました。

結果的には、unit test関係で想定していたセッションの内容は他のスピーカーの方々が行なっていたので、重ならずに良かったかもしれません。

運営の方からは良かったとフィードバックをいただけたので、推薦いただいたことに対しては役目を果たせたと感じてはいます。

他のセッション

すでに nowsprinting さんがまとめを書いていたので、テストに関してはそこにお任せ。
http://nowsprinting.hatenablog.com/entry/2017/03/05/061441

内容自体はprotocolやstruct付近を使った話で、functional programmingもかじっていると理解を深めることができる内容でした。

The Two Sides of Writing Testable Code

ここで出てきた “co-effect” に関しては以下が参考になるらしいので、少し読んでみようと思います。

ReactNative

3日目のハッカソンでは、その間に行われたReactNativeのゲリラワークショップを経験しました。

ReactNativeのテストには、JSレベルでは jest、UIレベルだと testID を付与してからのUI Test系ですね。
JSの世界でテストが実行できると、unit testでもXCTestよりも素早くテストのサイクルを回すことができて良いですね。

最後に

本当にお疲れ様でした & ありがとうございました

[Mac][RedwoodHQ]Run on Mac

RedwoodHQ on Macを過去書いた時点ではMacで動かすことができていなかったのですが、最近見て見るとLinux/Mac上でも動作するようになっていました。

http://redwoodhq.com/redwood-download/

からダウンロード・展開して、

$ ./start.sh

を実行、 http://172.0.0.1:3000 へブラウザからアクセスする、です。私はNode 4.7.2で実行していました。

ちなみに、このRedwoodHQは以下にフォークされてPRなどが取り込まれていました。

https://github.com/wolterskluwer-redwoodhq/RedwoodHQ

もともと作ってた人は退いたのかな。

[Java][Android]Error patternを検出する

Google製のFindBugsみたいなもののようです。

これのパターンに何があるのかは以下に書かれていました。

ざっと見てみると、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


以下、試しに適用してみたコミットになります。

これに対してビルドすると、generated codeに対してwarningが確認されました。
内容は http://errorprone.info/bugpattern/MissingOverride なのですが、ここら辺を見ているとGoogleのJava style gideに合致しているかも見ているのですね。