Allure2が開発途中だった

Test reporterの生成で有名どころと言えばAllureがありますね。Yandexのメンバが開発しているやつです。

最近、そのv2が開発されていることを知りました。

https://github.com/allure-framework/allure2

Gradleを使っていたので、早速Forkして使ってみることに。
人が増えて、テスト結果を複数人で見る必要が出てきた時に、こういう結果レポートから情報をざっと見ることができるツールはとても重宝しますね。

受託系の人たちはこういうことを欲する一方、Web系の人はそうでもない人も多いように見えます。
ただ、実施時間など含めて色々とまとめて情報をみたい場合、このようなUIを持ったツールは役に立つものです。

[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よりも素早くテストのサイクルを回すことができて良いですね。

最後に

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

[java]Parameterized test with JUnit4.12

最近知ったのですが、JUnit4のParameterized.classに name 属性を付与できるようになったのですね。

エラーの可読性などを見ると、組み合わせテスト用のDataPointsを使ってしまう面もありましたが、name属性が付与されるようになったことで、パラメータ化テストではParameterized.classをそのまま使えそう。

なるほどね…

[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に合致しているかも見ているのですね。

Architecture for GUI Testing(mobile)

In 2014, I talked about GUI testing architecture.

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     Abstract     Wrapper    Binding     Appium
(*.feature)   (*_steps.rb)  (*.rb)
     |           |            |           |          |
     |---------->|            |           |          |
     |           |----------->|           |          |
     |           |            |---------->|          |
     |           |            |           |--------->|
     |           |            |           |          |
     |           |            |           |<---------|
     |           |            |<----------|          |
     |           |<-----------|           |          |
     |<----------|            |           |          |
     |           |            |           |          |
  • Scenario layer
    • Describe scenarios.
    • This layer depends on “User scenarios”.
  • Abstract layer
    • Implement steps to run scenarios as Ruby code.
    • This layer absorbs the changes in scenarios.
  • Wrapper layer
    • Wrap binding.
    • This layer absorbs the changes in bindings.
  • Binding layer
    • Ruby binding

PageObject pattern is very famous. In this case, scenairo layer and abstract layer depends on pages. BTW, wrapper layer is common methods to help other layers.

「消極性デザイン宣言」を読んで、approchiabilityという言葉を知った

消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。」を読みました。

シャイハック。
私自身、ここに書かれていたように消極的な人間で、V字タイプな人。少人数や大人数だとある程度大丈夫だけれど、微妙な人数になると「・・・」となるような。

そんな人たちのコミュニケーションの話から入り、だんだんとモチベーション、インタラクションの話へと内容が移ってきます。個人的に面白かったのは、approchiabilityという考え方と、モチベーションの話。ここのモチベーションはやる気を出していく話ではなく、やる気がわかないことを前提とした(意識の低い)モチベーションの話なので、疲れず良かったです。

人間は基本的には消極的

これが基本的な立ち位置でした。消極的なので、自然にできるようにどうデザインするかとか、そういう話になってきます。

機能があることではなく、”機能する”こと、その機能を使おうとしやすいことなど。

Usability と Approachability

Usabilityは使いやすさとしてよく言われます。品質の話になるときや、人間工学の話、デザインの話といったように様々なところで出てきます。一方、Approachabilityという言葉は私が把握している限りでは初耳でした。

Usabilityとの対比としては、Usabilityが製品/サービスそのものの使いやすさを評価の対象とするのに対して、Approachiablityは対象となる製品/サービスがどれだけ”使おうとしやすいか”を評価しようとしている、という感じ。なので、製品/サービスのその周辺から連続した出来事を評価の対象に加えるという感じでしょうか。モバイル端末などの使いやすさとしてはこういった連続性に言及しているものもちらほら見ますが、そこに焦点を当てたものがこの”Approachiablity”という感覚を受けました。

使おうとしやすさ、行為の切り替え・接続、やめやすさ、いかに無理せず自然とできるか。

特別ではなく日常に溶け込む系のサービスとか製品ではこういう考え方って大事なデザインの話になりそうですね。

そういえば、インタラクションデザインにも言及していて、その中であったモチベーションの設計は色々なところで関係しそうな感じがしました。

締め

こういう書籍は時折読みますが、Approchiabilityという言葉の定義はなかなか良い発見でした。