Category Archives: software test

[iOS]What’s new Testingを見た

What’s new Testingを見た。 https://developer.apple.com/videos/play/wwdc2017/409/ 見ている途中でいくつかメモしたので、その記録として… multiple appのテスト、URLを引数で与えることできるのね Accessibility Dataのところで説明しているsnapshot、WebDriverAgentが使っているやつぽいな おー。いちいちsnapshot取得する必要がなくなるのか。実行時間改善しそう 要素の検索で全捜査でなくて最初にマッチしたものだけさっと返すようにした、という話だけれど、ようやくという感じ。 ここら辺は元からそうなのでそうよねという感じだ。 ここはどこまで厳密に書くかはどれだけ内部実装と結合を強くするかの問題ですね。Espressoでも同じ問題をもつ。 地味に嬉しい Activity styleの書き方、Cucmberとかイメージすると良さそう。stepsにいろんな処理を入れて、シナリオはstepsを並べて記述するような感じが使い方として近そうだ。 非同期の奴も良さそう。XCTestなので、XCUITestでも使えるし。 snapshotのところはほんといろんな3rd partyも恩恵受けるだろうし、良いことづくしな気がする。けれど、これはXcode8でないと使えないOSテストするときは恩恵受けられないので、完全に恩恵を教授できるのは数年後かな… Xcode9のいくつかの機能、Xcode9以前でも使えると恩恵大きくて良いな…More

[ReactNative][Test]Detox instead of Appium

2017/06/08現在 過去、ReactNativeに対するUITestに関して書いていたのですが、今の段階ではAppiumよりはDetoxを使うほうが、JSを経由したテストツールとしては良さそう https://github.com/wix/detox EarlGreyも参考にしている所とかあり、より安定したUIテストを実施するには現実的な気がします。 Androidのサポートも計画されているので、必要に応じてコミットしたいですね。 参考: [ReactNative][Appium]testIDの振られ方More

ICST2017メモ

ICST2017に参加して、会社のBlogには以下の通り少し書いたのだけれどGistに残したメモをGistのままにしておくのはもったいなかったのでメモがてら。 techlife.cookpad.com/entry/2017/04/04/180000 Google backend 4.2Mのテストコードが実行される 2年間、テスト結果は保持しておく 関係しているテストを見つける Life of test execution regression test selection => scheduler => build enqueuer => build queue => Massively parallel test backend => build failure retrier => build enqueuer …. => test results(マインスイーパのような形でgreen/redを表現) Analysis of test results at Google 84% of transition from Pass -> Fail are from “Flaky” tests…More

Allure2が開発途中だった

Test reporterの生成で有名どころと言えばAllureがありますね。Yandexのメンバが開発しているやつです。 最近、そのv2が開発されていることを知りました。 https://github.com/allure-framework/allure2 Gradleを使っていたので、早速Forkして使ってみることに。 人が増えて、テスト結果を複数人で見る必要が出てきた時に、こういう結果レポートから情報をざっと見ることができるツールはとても重宝しますね。 受託系の人たちはこういうことを欲する一方、Web系の人はそうでもない人も多いように見えます。 ただ、実施時間など含めて色々とまとめて情報をみたい場合、このようなUIを持ったツールは役に立つものです。More

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

私は職場で作ってきたテストの話のうち、UI Testに近いところの話をしました。 英語での発表は初めてだったのですが、一部想定通りに話せなかったところがありながらも無事に終えることができ、ホットしました。日本以外から来た人含め、いろんな人から英語も聞き取りやすかったし内容も良かったと言って貰えて、ひとまず安心しました。 20170302 tryswift tasting_tests from Kazuaki Matsuo お題の悩み 私は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 さんがまとめを書いていたので、テストに関してはそこにお任せ。 内容自体はprotocolやstruct付近を使った話で、functional programmingもかじっていると理解を深めることができる内容でした。 The Two Sides of Writing Testable Code ここで出てきた “co-effect” に関しては以下が参考になるらしいので、少し読んでみようと思います。 http://tomasp.net/blog/2014/why-coeffects-matter/ http://tomasp.net/academic/papers/structural/ ReactNative 3日目のハッカソンでは、その間に行われたReactNativeのゲリラワークショップを経験しました。 http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ https://github.com/KazuCocoa/MyArtistExample ReactNativeのテストには、JSレベルでは jest、UIレベルだと testID を付与してからのUI Test系ですね。 JSの世界でテストが実行できると、unit testでもXCTestよりも素早くテストのサイクルを回すことができて良いですね。 最後に 本当にお疲れ様でした & ありがとうございましたMore

[java]Parameterized test with JUnit4.12

最近知ったのですが、JUnit4のParameterized.classに name 属性を付与できるようになったのですね。 https://github.com/junit-team/junit4/wiki/Parameterized-tests https://github.com/junit-team/junit4/wiki/Parameterized-tests#identify-individual-test-cases エラーの可読性などを見ると、組み合わせテスト用のDataPointsを使ってしまう面もありましたが、name属性が付与されるようになったことで、パラメータ化テストではParameterized.classをそのまま使えそう。 なるほどね…More

[Mac][RedwoodHQ]Run on Mac

RedwoodHQ on Macを過去書いた時点ではMacで動かすことができていなかったのですが、最近見て見るとLinux/Mac上でも動作するようになっていました。 http://redwoodhq.com/redwood-download/ からダウンロード・展開して、 を実行、 http://172.0.0.1:3000 へブラウザからアクセスする、です。私はNode 4.7.2で実行していました。 ちなみに、このRedwoodHQは以下にフォークされてPRなどが取り込まれていました。 https://github.com/wolterskluwer-redwoodhq/RedwoodHQ もともと作ってた人は退いたのかな。More

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

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