Category Archives: software test

minimal ruby client for WebDriverAgent

WebDriverAgent developed by Facebook is one of WebDriver tool which run on iOS. Previous some posts, I investigated this module. And now, I develop minimal wrapper Ruby cli client to help some operations. https://github.com/KazuCocoa/wda_client I implemented some operations such as taking screenshots, getting source tree, status about the driver and install arbitrary app to the…More

memos ISSTA2016 for me

Site URL: https://issta2016.cispa.saarland/ Probabilistic Learning from Big Code / https://t.co/fnYjMG6VI6 — KazuCocoa (@Kazu_cocoa) July 24, 2016 Machine Learning for Programming とかしている人なんだ。 / https://t.co/OXfMFR8Iyx — KazuCocoa (@Kazu_cocoa) July 24, 2016 Cyber-Physical Systemsに対するコスト効率の良い手法を探して / Testing Dynamic Behaviour in Executable Software Model / https://t.co/9D84wXhj7N — KazuCocoa (@Kazu_cocoa) July 24, 2016 a search-based testing approachとな。initial desiredとfinal desiredを定義して、そのコストの最悪ケースを算出してシナリオを組み立てると。 — KazuCocoa…More

[Android]Try Espresso Test Recorder

AS2.2 Preview3がリリースされましたね。その中で、個人的に待っていたEspresso Test Recorderが実装されたので試してみました。 https://sites.google.com/a/android.com/tools/recent/androidstudio22preview3available 生成されたコードはこちら。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters package com.kazucocoa.droidtodo; import android.support.test.espresso.ViewInteraction; import android.support.test.rule.ActivityTestRule; import android.support.test.runner.AndroidJUnit4;…More

テスト計画とか(from GoogleTestingBlog)

Google Testing Blogの The Inquiry Method for Test Planning がちょうどまとめようとしていたことに重なっていたので、メモ。 ここでは大雑把なことしか書かないので、内容はGoogleのブログを読む、が良さそう。 test plan(テスト計画)の作成に関してです。 多くのソフトウェア開発においてテストを行う場合、実装コスト(implementation cost)、保守コスト(maintenance cost)、お金(monetary)、利益(benefit)、リスク(risk)を考える必要がありますね。 Test Plan vs Strategy この記事では、1つのテスト計画と、それらが多く集まってまとまったテスト設計、という関係性でテスト計画を定義しています。そして、その計画はだいたいがプロジェクトに依存する形です。 テスト計画必要？といった話も少しありますが、そこは置いておいて… リスク、カバレッジ、ツール、プロセス、ユーティリティという感じで内容は大別されてまとまっています。 リスク リスクドベーステストなどを行う場合、リスクの把握が大事です。例えば、データの欠損など。また、技術的な負債がどのくらいあるかとか、そういう技術的なところも大事。 カバレッジ ここでいうカバレッジはC0といった実装に閉じた話ではなく、もっと大きな枠でテストをどのくらいしているか？という指標です。S/M/L/Eのようなサイズ別のテストのそれぞれでどのくらいカバレッジがあるかとか、どのくらいmanual testingしたかとか。 ツール 環境整備やツールの用意などの話。 プロセス どのタイミングでテストを実施するかとか、バグレポート、市場に出た時にどうするかといった、リリースに関わるプロセス全般を考えるために。 Utility 誰がこのテスト結果を読むのか、とか。 締め 計画なので、ざっとしたまとまりな感じでした。ただ、こういった話はどこにでもあるわけではないので、ざっと読んでおくと良さそう。More

[Android]Dive into Toothpick

過去の調査に加えて、Toothpickに潜ってみました。 簡単なまとめ @inject アノテーションが付いている要素を、 scope.getInstance(); したクラスでinjectionして利用することができる。 inject可能な要素は木構造で表現され、親scopeに含まれる要素をinjectしたメソッド/クラスとして利用することができる scope外の要素を使おうとするとクラッシュ bind(IFoo.class).to(Foo.class) で Foo.class を使い回すことができるし、 bind(IFoo.class).to(new Foo()) では都度新しいinstanceを生成して利用可能 ActivityやFragmentといったライフサイクルに対して Toothpick.openScopes(getApplication(), this) してscopeを設定した場合、そのライフサイクルの onDestroy のタイミングでそのscopeをcloseする必要がある Scopeはアノテーションベースでも独自で設定できる 導入 ライブラリとして利用するための導入は こちらのWiki に任せて省略。 例えば、以下のFooクラスに対してinjectしようとします。 この時、scope.getInstance(Foo.class) したら、そのクラス内でこの Foo.class でinjectされている Foo、Bar、setQurtz を @Inject で指定して使い回すことが可能となります。 ついでに bind に関して少し触れておきます。以下のようにbindすると、 それぞれのケースにおいて以下のようになります。 case1 では、すでにFoo.class のインスタンスが存在するならそれを使い、それをIFoo.classに紐付ける case2 では、常に新たな Foo.class のインスタンスを使い、それをIFoo.classに紐付ける Scopeの種類 Scopeの種類としては2つ存在します。 a binding 都度、bindされるたびに新しいインスタンスとして利用される 子要素では親要素を上書き可能 bind(IFoo.class).to(Foo.class); みたいな感じで都度bindされるやつです scoped…More

[Elixir](UndefinedFunctionError) function List.Chars.to_charlist/1 is undefined or private with Elixir 1.3.0

https://github.com/elixir-lang/elixir/releases/tag/v1.3.0-rc.0 Elixir 1.3.0では to_char_list がsoft deprecatedになり、 to_charlist にリネームされました。 そのため、例えばelixir 1.2.x以前でビルドしていたバイナリが存在している状態で 1.3.0 で 再ビルドなし でコマンドを実行した場合、エラーが発生します。 例えば、 Doctest の場合、以下のようなエラーが表示されました。 これを解決するには、 _build を削除して再ビルドすればOK。この逆もありました。注意が必要ですね。 あと、もう1つ。ExUnitに標準で describe/2 が入ったことは良いですね。1段のコンテキストの分離はだいぶグルーピングに使えそう。 shouldi を使わなくても良くなりそうです。 注意が必要。More

[Android]ToothpickでTree Based DI

最近、Tree Based DIツールのToothpickを知りました。 https://github.com/stephanenicolas/toothpick このメンテナは、RoboGuiceをメンテしていたGrouponの人です。RoboGuiceの更新を見に行った時にたまたま見つけました。ここ数ヶ月で作り上げられたDIライブラリのようです。このリポジトリWikiのあるページに、AndroidにおけるDIの歴史や経験をまるっと学ぶことができて良かったです。 https://github.com/stephanenicolas/toothpick/wiki/FAQ#why-creating-toothpick- さらには、彼らがRoboguiceからDagger1/2と触れた上でこのToothpickを作るに至った流れも書いています。 まだWikiと簡易サンプルをさっと眺めた程度なのですが、備忘録がてら。 AndroidでToothpick Toothpick自体はJavaのTree Based DIです。これ単体ではAndroidはサポートしていません。Androidをサポートするために、smootheがあります。 このサンプルにあるように、Toothpickはsmoothieを介してAndroidにDIを提供します。 幾つかのDIツールとの速度比較 Roboguice4/Dagger1/Dagger2/Toothpickのinjectionするメソッドの個数による速度差が以下の通り。 https://github.com/stephanenicolas/toothpick/wiki/Benchmark#benchmark-raw-data Androidの環境でいうと、injectionするメソッド数が1000個超えるとかな大規模なものになることはまだそこまで多くはないはずなので、速度としては申し分ないのではないでしょうか。 初期設定では一部reflectionを使っている 以下の通り、default設定ではfactoriesの読み込みやmember injectorsを読み込むにあたりreflectionを使っているらしいです。 https://github.com/stephanenicolas/toothpick/wiki/Configurations ただ、このreflectionはOFFにすることができるそうな。そのためには以下の通りToothpickを使う時に reflectionFree の設定を与える必要があるとのこと。これにより、完全にToothpickはreflectionなく動作し、高速になると。 ベンチマークはこちら => ★ 確かに、reflectionの有無で何倍も速度差がでますね。ここら辺の積み重ねで性能差が大きく出てきそうな。 scopeにより意図しないクラッシュを避ける Scopeという概念を入れることで、Scopeに属さないfragmentなんかを意図せず読んだ時にクラッシュする、というような不用意なinjectionを回避できるようにしているそうな。ここはまだこのツールの中身を追ってはいないのでなるほどなという感じ。 あと、ここなんかでは、メモリリークに対するこのツールの見解といったところも記述されています。 締め まだざっとWikiなんかを眺めただけで中身を追ってはいないのですが、tree based DIが、学習コストがあまり高くなくとも比較的容易に使えるライブラリなのであれば結構有力なDIの選択肢になるのではないかなと感じています。個人的には、toothpickにはテストコード向けの機能も提供しているので、テストコード書くにあたってもかきやすいものであればなお嬉しいなという感じです。シンプルにinjectionするモジュールの関係性や使い方を理解して使えるのであれば、内部品質向上へ大きく寄与するし、テストコードを描きやすいのであればクラッシュや機能不全などの外部品質の担保にも寄与できると期待できるためです。 ちなみに、過去、私はDagger2を学んでいました。このBlogの過去のDagger2関係 => 検索 その中でDagger2を使ってテストコードのDIによるテストも書きはしたのですが、そんなに簡単に書けた！というほどでもなかった記憶が。。。 ともあれ、Dagger2と同じくらいには使い方などを追ってみようと思っています。(少し気長に…)More

Reading “Software Testing: Essential Skills for First Time Testers: Software Quality Assurance:From scratch to end”

Software Testing: Essential Skills for First Time Testers: Software Quality Assurance:From scratch to end (English Edition) を読みました。 job descriptionとか、その必要とされるスキルセットに関して情報を集めたかったので。 この書籍は、まだSoftware Qualityに関して知見の少ない人を対象に、全体像を提供したり、より詳しく調べるならここ見てねという簡易ポインタを提供するものでした。”品質の高いソフトウェア = バグゼロ”だけではないことや、バグを作るこむことを防いでいくことが必要、というようなことが入りです。そこから、最後にはインタビュー形式でのキャリアを歩んでいる人の事例紹介まで乗ってました。 続けてよくある不具合のつくり込みとして以下が挙げられていましたが、その通りですね。よく言われ続けていること。 要件/要求定義 不十分な設計文書 プログラミング知見の不足 コミュニケーション不足 時間のプレシャー この他に、ソフトウェアテストのライフサイクルなど。全体的な話もまとめてされています。 テストだけではなく、品質を上げるために必要な開発体制に関しても言及されていました。反例としてビッグバンモデルの開発体制から、アジャイルな体制などの開発体制に関する内容まで。 私が求めていたようなjob descriptionレベルの新たな発見はなかったです。が、頭の中を軽く整理したりしたい人には良いものな感じです、短いのでさらっと読めますし。More

[Android]Google Test Labs to Firebase

Google Test Labsを覗いてみると、以下の通りFirebaseに移行したとありました。 Firebaseに統合されていることは知ってたのですが、完全にFirebaseの一部に移行するのですね。モバイル系プラットフォームのFirebase化への本気度を感じます。 Test Lab is moving to Firebase. Visit the Firebase console to use Firebase Test Lab for Android. 以下にドキュメントがありました。 https://firebase.google.com/docs/test-lab/#implementation_path サポートしているスクリプトは以下のよう。 Espresso, Robotium or UI Automator 2.0 instrumentation tests written specifically to exercise your app. Robo test, which analyzes the structure of your app’s user interface and then explores it automatically by…More