最近、Googleのcodelabsを覗きながらGoogleIOであった新しめなツールの把握をしています。 https://codelabs.developers.google.com/ どのくらい時間かかりそうかも書いているし、実際経験したことある人だと表示されている時間ほどチュートリアルにも時間がかからないので効率的にざっとした内容は把握できそうな気がします。 ConstraintLayout ConstraintLayoutを試してみました。 こちら AppleのStoryBoard上でAutoLayoutを操作する感じで使えますね。 サンプルを基に、自分で少しやってみました。 https://github.com/KazuCocoa/myconstraintlayout XMLは微調整をする時以外見なくてよさそうな感じまでなると良いですね。古くからAndroidアプリ開発されている方はXMLとの対話の方がまだ効率的なのかな。 Android Testing Codelab こちら これはオマケみたいなものです。 Espressoを使ったサンプルと、MVCの説明ですね。Activityへの依存性を少なくしてテスト可能な範囲を広げるとか、interfaceを定義してその実装をstub/mockするやり方とか、そこらへんの導入が書いています。 Espresso-contrib はRecyclerViewに対して使えるメソッドを提供していたのは知ってたのですが、 DrawerActions や DrawerMatchers に対してもそうであったのですね。ここは知らなかった… (と思ったら、ATSLのページには書かれていた.. Espresso-contrib for DatePicker, RecyclerView, Drawer actions, Accessibility checks, CountingIdlingResource) あと、@SmallTest, @MediumTest, @LargeTestの説明あったけれど、社内で定めた基準とだいたい同じ感じ。 そういえば、Espressoでは、waitとか用意しなくて良いのね。Espressoのテスト、ちょっと調整しよう。 Espresso waits until the UI is idle before it moves to the next operation. Likewise, it waits for AsyncTask…More
Category Archives: software test
[iOS]EarlGreyを使ってシナリオを記述する
過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。 対象のproject: https://github.com/KazuCocoa/MyGithubSearch 対応コミット: https://github.com/KazuCocoa/MyGithubSearch/commit/bd83bf8668260978ec6941bd8c003470c9443167 幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。 EarlGreyについて EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility Protocolを操作する。 リポジトリはこちら。 https://github.com/google/EarlGrey EarlGrey自体の説明はあるのでここでは書きません。 セットアップ、導入 https://github.com/google/EarlGrey/blob/master/docs/install-and-run.md Swiftサンプル https://github.com/google/EarlGrey/blob/master/Demo/EarlGreyExample/EarlGreyExampleSwiftTests/EarlGrey.swift 何か困った時 使えるAPIや、使い方がわからないとか、そういう時はテストコード読んだりAPIドキュメント見るとある程度対応できます。 APIドキュメント https://github.com/google/EarlGrey/blob/1.0.0/docs/api.md Matcherの実装 – どのように動作しているか、といった説明も書かれているので、ざっと一読することをお勧めします – https://github.com/google/EarlGrey/blob/master/EarlGrey/Matcher/GREYMatchers.h – AccessibilytLabelやidentifierの他にも、Valueなど多くの要素が使えるのよいですね – ただ、 We strongly recommend using an accessibility identifier as it uniquely identifies an element. と書かれているように、やぱり accessibilityIdentifier を使うことが良いことには変わりなさそう。ここは激しく同意。 Other Tips 要素を見つけたい時 シミュレータだと、AccessibilityのAccessibility Inspectorを有効にしてそれを使うと良いです…More
[Elixir]concurrent integration test with Hound and handle it with tag
雑にしか書きませんが、Phoenixのcontrollerのテストでは、あるURLへの操作に対する結果のチェックにはstatus codeが何か、そのtitle要素は何かといった簡単なHTML要素をみます。そこは静的な要素をチェックできるのですが、画面の遷移が絡んでくるとintegration testと呼ばれる段階のテストを用意する必要があります。 Elixirでは、その手のツールに以下の2つがあります。 Hound Wallaby Wallabyのほうが後発です。これはconcurrentなテストを主眼に開発されているようです。ただ、対応ブラウザがPhantomJSだけだったので、私はHoundを選びました。 そして、concurrent integration testを行うにはphoenix_ecto3.0 + Ecto 2.0を使う必要があります。これは、Ecto2.0から入ったownership制のsandbox環境を使い、concurrentなテストを実行する必要があるためです。 ※Ectoのこのownership制の話とか気になる人はこちらを読むと良いと思います。コード 設定 以下の設定説明を参考にすると、基本的なところは完了。サクッと実行できます。なのでここではリンクだけ… https://github.com/phoenixframework/phoenix_ecto#concurrent-acceptance-tests https://github.com/phoenixframework/phoenix_ecto#hound 私はfirefoxとWebDriverのstandaloneを使ってサクッと実行しました。 WebDriverはこちらからダウンドード可能です=> https://selenium-release.storage.googleapis.com/index.html tips 通常、この手のintegration testはブラウザを使うのでテスト実行が遅かったり不安定だったりします。そのため、その他のmodelやcontrollerのテストとは別に制御できるようにして、不要なときはskipするなりしたいです。 ここでは、tagを使って制御しましょう。ただ、よくあるメソッドごとに @tag をつけるのでは煩雑になるいっぽうなので、 integration_case.ex なんかを作って、それを読み込んだ全てのモジュールに対して勝手にtagがつくようなやり方です。 tagを付与する support/integration_case.ex にtagを設定する 以下のようにヘルパーを作ってあげると、 use MyApp.IntegrationCase したモジュールは自動的に @moduletag :integration のtagが付与されます。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than…More
とてか04で多くのものを拾ってきた
とてか04とは 『とちぎテストの会議04』が正式名称。 toRubyを主催している方々が、主に”テスト”に関わる何かを主において開くイベントです。 その中で、今回は以下の通り「つくるいとなむ」を主なタイトルとして開かれました。 http://d.hatena.ne.jp/tochigitestnokaigi/20160423 私 私は以下のようにLTの1番目として発表いたしました。 これ自体は私の普段の学び方だったり、その中で特に業務に活かすために特に疑問に感じていたことをお話し致しました。 「チョットデキル人に訊け！」ででた”テストをうまくなるには？” こちら、何が自分、ひいては周りの向上を誘うか、ですよね。私も考えてみたのですが、やっぱり以下のようにやりたいことベースでいろいろ学ぶなーと感じました。それ以外だと、業務上だったり一時の知的好奇心から、というのはちらほら。 うまくなるには、みたいな話、私なりに考えてみると結局はやりたいことあるからベースが一番強そうです。 #toteka — KazuCocoa (@Kazu_cocoa) April 25, 2016 これ以外だと、何か興味を持っていることの周辺でテストに絡めて学ぶ、というのが面白いのでないですかね。 拾ってきたもの 多くの方々とのつながり。 とてか03で初めて足を運んだとてか。そこから1年後の2回目。前回よりもいろいろな人と話をしましたし、つながりもできました。これは私にとってとても良いつながりだと感じます。ありがとうございました。More
Espresso-core2.2.2とRunner/Rules 0.5が公開されていたのでコードを見る
espresso 2.2.2と、Runner/Rules 0.5が公開されていた。Silent releaseぽい。 https://google.github.io/android-testing-support-library/downloads/release-notes/index.html 更新情報の中で気になったところをメモ。sampleとかも書かれていないので、コードを直接追ってみました。コードまで追ってみた結果としては、 withResourceName だけ気にしていれば良いかなという感じ。 New feature Added checks for enabled animations and transitions New ViewMatcher API: withResourceName notable change ActivityTestRule, UiThreadTestRule, IntentsTestRule and ServiceTestRule are out of beta. dive into code withResourceName コードを見た感じだと以下。 withResourceName は resource idではなく、name属性から要素を特定できるっぽい。 android/support/test/espresso/matcher/ViewMatchers.java This file contains hidden or bidirectional Unicode text that may be interpreted or…More
Keep Agility with Rapid Deployment
Steve McConnell氏のRapid Developmentを読みました。90年代の書籍。日本語訳はこちらに。ラピッドデベロップメント―効率的な開発を目指して Rapid Developmentは、短いスケジュールで開発をどんどん回していく、という考え方を持った開発スタイルです。最近のAgileの風潮に対して、以前からそういう開発スタイルが提唱されていた、という参考になりました。 ただ、読書を進めていくと、開発プロセスに関するところは大学で教授から学んだことと大半が重なってて、なんか講義を見直している感じがしました。 Part1. Effective development For every complex problem, there is an answer that is short, simple, and wrong. — H.L. Mencken 人に関する問題が、最もソフトウェア開発や品質に影響を与える、と早い段階で書いています。また、”Motivation”が強く影響する、とも書いています。 Classic mistakeとして幾つか実例を挙げています。分類として、人、プロセス、製品、技術に関わるところから。いずれも、昨今のAgileの文脈で言われることの多い従来の開発における問題やらなんやら書かれています。これを見ると、結局は問題は古くからあって気づいた人はどうにかしようとしている、ということを知ることができます。 ソフトウェア開発に関わる活動のプラクティスを、Management、Technical、Quality-Assurance の面から色々紐解いています。その中では、例えばエラーが出やすいモジュールに対する言及や、Testing、レビュー活動など、現在やっているプラクティスがもろもろ含まれていました。 リスクマネジメントのことも。リスクを識別し、分析、優先度をつけて可能な領域で制御する。そこらへんも書いていたり。 ここら辺を書いていますが、個人的に良かったのはそれらをまとめ、体験としてまとめているところでした。昨今の開発全体を書いている書籍を読むよりは、これを読んだ方が有益な感じがします。 Part2. Rapid Development Part2では、今までの一般的な効率的な開発の説明のなかから、Rapid developmentとしてのプラクティスをまとめています。 Agileのプランニングポーカーみたいなタスクのサイズの計測とか、そういう話に似たものも出てきます。いずれも、時間に対してどこまでやるか、を現実としてどうするかに関する話を交えています。 変えることができるところ、できないところを分けて、いろいろ試行錯誤している感じですね。 ただ、現在とは使える周辺ツールにより当時では時間がかかっていたことも短時間で実施できるようになっていることもあり、書籍の数値が完全に正しいというわけでもありません。一方で、考慮しなければいけない要素自体は、ソフトウェア開発という文脈ではとても参考になるものです。 ここには 時間、コスト、実装する機能の量に関するトレードオフ に関しても、すべて書かれています。なので、昨今のAgile開発に類する開発本を読むよりは、この書籍を読む。その上で、当時問題だったところから現在までに変わったところ(例えば、自動化されたテスト環境とか)を把握していく方が、しっかりとした考えを備えることができそう、と感じました。 というか、90年代の書籍に開発の根本的な要素がまとめられた書籍が多く、それらが現在の開発においても色あせていないところが多い。それは逆に、ツールが発展しつつも、そのコアとなる問題は変わっていないし、 その問題解決は簡単ではない ということなのですかね。 このRapid developmentの開発プロセスのwaterfallとか、spiralとか読んでいると、大学の頃に学んだことに近い、そのまんまなところが頭に浮かんできた。。。 要求分析の話とかも。 面白かったのは、high-performance teamというように、チームで高い成果を出すための大事な要素もまとめられていたところです。人やチームに対する考察も、しっかり書かれているのは素敵ですね。その中で、特に 楽しもう!! が1つのトピックで書かれていたところが印象的。アンチパターンも多くのっているところも良かったです。ここらへんは昨今のAgileの文脈とか、開発プロセスの話でよくでますね。時代は回る〜。 Silver-Bullet…More
[Elixir]Ecto2.0-beta2のownership周りのコードを追う
Ectoが2.0(beta)になって、concurrent acceptance testingができるようになったのでいくつか調べてみた。 参考にした元記事は以下。 Concurrent Acceptance Testing in Elixir この中で、Ectoのownershipのところが気になったのでいくつかコードを追ってみました。 Ownweshipを取得する時、 Ecto.Adapters.SQL.Sandbox.checkout/2 が呼ばれます。 これはEcto2.0で必要になったところですね。 https://github.com/elixir-lang/ecto/blob/v2.0.0-beta.1/lib/ecto/adapters/sql/sandbox.ex#L281 ここの中で、もしsandboxであれば にあるように、ownership_poolのキーを持つDBConnectionのプロセスをとってきます。 これは、以下のdb_connectionのコードを呼びます。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership.ex#L47 この中で case されるのは以下。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership/manager.ex#L19 この DBConnection.Ownership.Manager はGenServerになってて、その自身に対して call します。 :checkout が call されるところを探すと、以下がみつかります。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership/manager.ex#L149 ここで、DBに対して処理を行うプロセスがcheckoutされていない場合、以下のprivateメソッドが呼ばれます。 https://github.com/fishcakez/db_connection/blob/v0.2.4/lib/db_connection/ownership/manager.ex#L174 こう見ると、この段階でetsに対してcheckoutした、ということを保存するのですね。なるほど。 もう1つ。以下の通り allow されることがconcurrentlyにテストを実行する上では必要です。 これは、以下の通りドキュメントに書かれています。 https://hexdocs.pm/ecto/2.0.0-beta.1/Ecto.Adapters.SQL.Sandbox.html Summing up – Using allowances – requires explicit allowances via allow/3. Tests may run concurrently.…More
[Erlang]Dive into Designing for Scalability with Erlang/OTP
Designing for Scalability with Erlang/OTPを読みました。Erlang/OTPを軸とした、スケーラブルなシステムを構築するための設計に必要な知見がたまってそうだったのと、半額程度で購入できたのでありがたく読みました。 内容として、半分はErlang/OTPのエコシステム周り、設計思想とかの話でした。ただ、残す半分はErlangに限ったことではない、広く使えそうな基礎がまとまっていました。個人的には、Elixir in Actionと合わせて読むとこの系統の書籍は十分そうな感覚です。 ちなみに、所どころ使われている例題や、それを個人的にElixirに書き直したものを以下に置いています。(所どころ壊れているものもありますが。) https://github.com/KazuCocoa/erlang-scalable-design 前半部分 Erlang/OTPの全体的な話が書かれています。背景とか。message passingの概要とか。諸々。Erlangの文法も学びながら、gen_serverだったり、gen_fsmだったりといくつかのOTPの話に発展する感じでErlangを学ぶことができます。 debugのための、sysやdbgモジュールも記載されていました。以前読んだQiitaのReconTrace で Erlang VM のトレース機能に親しむでかかれていたrecon_traceなんかのことも言及されています。 proc_libという特別なプロセスの話も。この特別なプロセスは、 システムメッセージや、イベント、シャットダウンとが可能 動的モジュールのリストを得ることができる debug flagを使ってトレースメッセージを利用することができる といった特徴があります。 後半部分(Chapter13以降くらい) Chapter 13のDistributed Architectureは、SOAやP2Pといった大局な設計やinterfaceから、その配布方法などの話まで色々ありました。これはErlangに特出したツールの話以外は、普通にErlang以外でも役立ちそうな情報だと思います。 リリース関係の話の中で、riakというdecentralized datastoreなツールの話もあって、面白かったです。Gossip protocolを使ってClusteringしているとか、そういう話も載っていたので。HashiCorpのSurfなんかでも結構知られていますね。Gossip protocol。 Riakのそこらへんのドキュメントはこちら http://docs.basho.com/riak/latest/theory/concepts/Clusters/#Gossiping http://docs.basho.com/ これのErlang client https://github.com/basho/riak-erlang-client Elixir client https://github.com/drewkerrigan/riak-elixir-client Scalableなシステムを組むためのtipsとして、以下の項目がまとめられていました。 分割する Distributed architectural pattern(cluster, SOAなど ) Network protocol node間のinterfaceや状態も持ちようやデータモデル node間のretry strategy node間のsharing data…More
RedwoodHQ on Mac
http://qiita.com/ootaken/items/e6e85e7b91cb98b2e294 で知ったのですが、RedwoodHQというOSSのtest automation frameworkというものがあるらしいですね。 https://github.com/dmolchanenko/RedwoodHQ Webページを見るとどうやらサーバの動作環境のメインはWindows環境。 ただ、githubを見る限りはJavaとNodeぽいのでmacでもちゃんと動くだろうと思って動かしてみました。 必要だったこと。 mongodbをインストールする それ以外は、基本的に git clone する top directory で npm install する mongod を起動した上で、 node app.js agent配下で npm install node app.js (in agent) これで、 http://localhost:3000 でサーバ http://localhost:5009 でAgent にアクセス可能になります。 ただ、私の環境ではAgentへのアクセスの時にサーバからの応答はあるのですがページが表示されなかったので(not foundが返ってくる)、うまく動いていない部分があるのかもしれないです。そこらへんは少し見てみないといけなさそうでした… https://t.co/gdIFQkRmjF にあるRedwoodHQ、nodeなのでやればフルでMacやLinux上で動作させることできそう。私はAgentがイマイチできていない。ちなみにDBはmongodb使っている模様。 — KazuCocoa (@Kazu_cocoa) February 24, 2016More
デブサミ2016でモバイルアプリ開発に関してお話しさせていただきました
以下の通り、お誘いいただいたこともあって、デブサミ2016でお話しさせていただきました。 http://event.shoeisha.jp/devsumi/20160218/session/1055/ Googleのとある書籍に習って、テストに関わる職種から見た開発、というものを書いてみました。ただ、ハードウェアは関係ないので”ソフトウェア”をつけています。 がっつりソフトウェアテストの技法だとか、どう活用しているという話は JaSST や SQiP でされる方がよくて、デブサミでは 自身の体験をもとにしたその周り 、という形の方がイベントの趣旨としても良さそうだったので今の物語の流れにしました。聴講者、デブサミは開発よりな人だったり開発上がりのマネージャな方なイメージだったので、時間帯も考えるとがっつりテストの話は眠くなりそうと感じたので。なのでQualityを真ん中に置いてその改善という流れにしてみました。 テストという局所的な話よりも、開発全体の中でQualityを高めるためにどうしたか、その中でテストエンジニアというものがサービス開発にどう関わっているのか、貢献しているのかが一連の流れで分かると良いなと思いました。 テストというQualityに対する一部を取り出してそこだけに深く関わるのではなくて、こういう感じで広く関わって、品質を向上させるところに 知を使う のがテストエンジニアとか、QAエンジニアと言われる方々。ソフトウェアテストの開発の上流工程から〜と言われるところの仕様というところをさらに広げた、多分もっと根本的にあったであろう活動全般になるのでないかな。(と信じてはしますが…)。日本でいう、1990年代にあったとされる品質活動と同じようなことをしている感じ。（実際にはその頃の話は聞いただけなので、想像ですが…） 品質に対してアリストテレスの話を出したのですが、そこらへんも反応がなかったので “がっつりソフトウェアテストの技法だとか、どう活用しているという話は JaSST や SQiP でされる方がよくて” という判断は正しかったぽい。(多分、そこ専門に学んでいると多少なりとも知るのでないかなと思ったので)。でも、そのあとのとある会話でSQiPやJaSSTでもそんなでもないかも、と言われたので、そんなでもないのかも。 あ、 toteka の宣伝の箇所が一番ウケがよくて、良い緩和剤になってくれました。 運営に携わっていました方々、ありがとうございました。More
~ my tech diary ~ 