[Android]duplicateFileException when import espresso-web

個人アプリのいろいろなライブラリの更新をしていると、以下のようにespresso関係でエラーが出るようになってました。 Webでざっと調べると、以下を見つけることができました。 http://openstackwiki.org/wiki/Espresso-Web_importieren_verursacht_duplicateFileException http://stackoverflow.com/questions/33800924/espresso-web-import-causes-duplicatefileexception 公式では、以下のcontribにはcoreが入っていると書かれているのでその場合はcoreは不要、とは書かれてれているのですが、これはよくわからなかったです。 ちなみに、以下のGradleサンプルでは大概のespressoに必要なものは入ってました。 https://google.github.io/android-testing-support-library/downloads/index.html ひとまず、stackoverflowにあるように以下を packageOption に追加することでエラーを回避することができました。んーむ。More

OpenSFT

完全なメモ。 OpenSFT を試した。リリース直後は確か何かつまづいてそれ以降試そうとしていなかったのだけれど、また試してみた、といった具合。 単純に、on Mac OS X 10.11で試したが、 stf local では特に問題なく動作しました。LDAP機能もあったし、社内連携も多少は行けそう。 ふむ。More

『アジャイルの魂2015 アジャイル開発者18人の物語』を読んだ

『アジャイルの魂2015 アジャイル開発者18人の物語』を読んだ。 私が気に入ったところはいくつかあった。が、その中で気に入った言葉がある。 QAおじさんのアジャイル奮闘記にある、 Stealth である。 ただ、この言葉に感じたものは私はこの著者である永田さんとは異なるかもしれない。 私が感じている、というよりも、ずっと意識しているのは 自然に居ること である。その中に溶け込むこと。なので見えない、というよりは異なる。だが、その意味は変に意識しなくとも開発に対してテストする人も、コード書く人も、ディレクションする人も普通に居る。そんな世界。 なので、私はこの言葉がこの書籍の中で気に入った。More

『ハワイの歴史と文化』を読んだ

ハワイの歴史と文化―悲劇と誇りのモザイクの中で (中公新書) を読んだ。 移民の話、パールハーバーの話、観光地としての話、これからの話とハワイの重要な歴史を知ることができました。特に、日本人の関わり方という点でもまとまっているため、過去どのような関係を持っていたのか知ることができました。 海外や知らないところに行く時、私はその場所などに関して多少なりとも知見を得て向かいます。教授から学んでいた時に、その地域のことを多少なりとも学んでいくことがわかりやすい礼儀になるという話を聞いてからそう言った習慣がついた気がします。More

[Elixir]Lint with dogma

Elixirのlintツールとしてdogmaというものがあります。 RubyのRobocopのようなものですね。 https://github.com/lpil/dogma 試しに適用してみました。修正も。備忘録に、以下2つ。Phoneixの簡単なアプリとhttp_proxyを。 http_proxy https://github.com/KazuCocoa/http_proxy/pull/21/files sample web app https://github.com/KazuCocoa/web_qa_vote/pull/6/files Report formatとしてJSONもしてい出来ます。 https://github.com/lpil/dogma/blob/master/docs/reporters.md この標準出力を解析して、例えば dokumi と組み合わせるとPR時にlintを指摘する、というのもできますね。 ※ 最近は credo を私は使っているMore

『ヒューマンエラー 完訳版』を読んだ ~ これが否応のない人生の現実である ~

単に、どんなにうまく運営されている組織でも、影響の大きな意思決定のうち相当の数が、後になって間違っていたと判明することになるという事実を認めることである。 これが否応のない人生の現実である 。 『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだであったような欠陥分析をする上で、人は一定確率で失敗するという大事な前提があります。一方で、それはどれほどなのか、経験的なものではなくちゃんと研究としてどこまでされているのか気になっていました。 そんな中、『ヒューマンエラー 完訳版』を見つけたので読みました。そのメモなどをつらつら。 ソフトウェアは人工物です。そのため、ソフトウェア開発は人の組織や認知と如何に関わるかというところが大事な要素を占めてきます。(ソフトウェアテストを学んでいると多くの人は行き着くことな気もしますね) この本では、主に原子力発電という安全性が最重要とされる情報をもとに、ヒューマンエラーに関して研究をまとめています。ここら辺は、安全性が重要な要素である航空関係、医療関係でも使われていることでしょう。たとえば スライスチーズモデル なんかで。一方で、 スライスチーズモデル の考え方なんかは、実は程度はどうであれそこ以外の分野においても有益な情報が多分にあります。 学術的な箇所は端折ってメモ。 GEMS(Generic Error-Modeling System)に沿った定義でエラーを主に扱っている 実行上の失敗: スリップ(しくじり)、ラプス(手抜かり) 計画が不適切: ミステイク(mistake) この中で、計画が不適切であるエラーの方がより見つけにくい。(ソフトウェア開発だと、仕様がそもそも誤っているというところですね。) 人の活動は、 SB: skill base RB: rule base KB: knowledge base の3つで構成されるとしている。それぞれの特徴は省略(本書のP.82付近)。この中でSBで発生するエラーは、主には 監視の失敗 によっている。RB、KBは問題解決能力が大きく関係してくるエラーに対する活動。 人は、 頻度の高いものほど認知/推論しやすくなる 。逆を言うと、そうでないものはエラーを認知することが難しくなる。5章ではそんな人の認知のロジックをモデルに落とし込み、模倣した研究が添えられている。つまり、人の正しいが、時折間違えるという状態がモデルとして扱われ、それを計算機により表現している。 第6章の数値は面白かった。データベースアクセス、更新などのある作業が エラーなくできたか、エラーが発生した時に正しく対処できたか を、SB/RB/KBで対策した時の差を計測結果として残している。 これによると、 SB ほどエラーが発生しやすいが、同様にSBの人ほどエラーが発生した時に正しく対処できる可能性があることを示している。 つまり、プロセスなどを整備することによるリスク低減と、人のスキルが成熟している状態を作ることができれば、低いリスクで万が一にも備えることができる状態を作り上げることができる。 ただ、いずれの活動に置いても、 手順の飛ばし、抜け、漏れは検出することができなかった。つまり、 手順の抜け漏れを探すようなことは、人は苦手。 エラーを検出するためには、 自己監視過程 なんらかの環境の手がかりに気づく 誰か他の人が発見する が大事。特に、ほかの人による発見は複雑でストレスの高いものほど効果が高い。つまり、 気をつける 、…More

『スペキュラティヴ・デザイン』を読んでみた

スペキュラティヴ・デザイン 問題解決から、問題提起へ。—未来を思索するためにデザインができること を読みました。デザイン思考と違うのかなとか思ったり、speculativeってなんだ?というところがきっかけです。 思考を発散させたいような人は読むと良いかもしれません。一方で、いろいろと思考実験したり考えることが好きな人にはあまり実りはないかもしれないですね。 この本で提示するspeculative designは、課題を見つけて解決するためのデザイン思考からさらに進んで”問題に対して考える”ためにデザインする、というもの。比較として課題解決のためのデザインとしてアートとしてのデザインや工学的な設計のデザインなどをとり上げながら、speculative designに対する取り組みをいろいろと書いています。 結果的には、変化するためにいろいろ思索するきっかけを作ったり、考えていこう、というものですね。その印象が強かったです。More

『Mobile Testing Interview Questions & Answers』を読んだけれど、これは入り口向け

Mobile Testing Interview Questions & Answers: Guide to Crack Interviews (English Edition) を読みました。 この内容は、Q&A形式でモバイルアプリのテストに対する幾つかの疑問に答えていく、というものでした。 ターゲットが以下なだけあって、内容としては基礎的なものです。内容は前半がモバイルアプリのテスト全体に対して、後半がAppiumに対してです。 a beginner who has never faced any Mobile Testing interview Anyone who wants a bried on Appium Professional who want answers with example and explanation One who don’t know what “They” really want to hear… 環境の設定変更といった具体的な話もありました。ただ、すでにモバイルアプリのテストを実施したことのある人、またはAppiumを試したことがある人、からすると目新しいものはない感じです。 これは本当に知見のない人に対して行う説明、といった感じですね。More

[Elixir]ExUnitで同名のtestが存在した時にコンパイルエラーにする

1行まとめ ExUnitにおけるテストケースの重複時にコンパイルエラーにしたい場合、 test_helper.exs に Code.compiler_options(warnings_as_errors: true) オプションを追加しておこう 多分、これはチーム開発では大いに役立ちます ExUnitが test マクロを関数定義するまで 以下のようなテストケースがあったとします。 この時、 test マクロで定義されたところは __ErrorSampleExunitTest__.’:test the truth’ としてコンパイル時に定義されます。 Elixir1.2.1では以下の行での話になります。 https://github.com/elixir-lang/elixir/blob/v1.2.1/lib/ex_unit/lib/ex_unit/case.ex#L258 同名の test が存在した場合 さて、この時に複数の同名のテストが存在した場合はどうでしょう? 例えば以下。 この場合、コンパイル時にCLIで以下のような warn が表示されます。 test/error_sample_exunit_test.exs:8: warning: this clause cannot match because a previous clause at line 4 always matches テストケースを記述するコードは、 .exs の拡張子を持つので、このようなwarnはテスト実行毎に表示されます。なので、実行を注意深く見ていると、このエラーを知ることができます。 ただ、他のテスト自体は実行されます。 コンパイルエラーにする ただ、warnではなくコンパイルエラーにしたほうが親切なのでは?と思い、手元でコンパイルエラーになるようにExUnitを直接修正してみました。 ExUnitのtestマクロでは、以下の2点でコンパイル時に関数を定義します。 https://github.com/elixir-lang/elixir/blob/v1.2.1/lib/ex_unit/lib/ex_unit/case.ex#L258 https://github.com/elixir-lang/elixir/blob/v1.2.1/lib/ex_unit/lib/ex_unit/case.ex#L280 なので、その直前で以下のように既存モジュールに定義済みの同名関数があるかどうかを検出させ、trueであればraiseするようにします。 コンパイラオプションで回避する…More

SauceLabsのMobile App Testing Checklistがまとまってて良かった

SauceLabsのメルマガで、良いチェックリストがあったのでメモ Mobile App Testing Checklist from https://saucelabs.com/resources/white-papers/dzone_2015_spotlight_guide_to_mobile_development-sauce_labs.pdf Device Checks ☐ Can the app be downloaded? ☐ Can the app be uninstalled? ☐ Can the app be updated? ☐ Can the app be updated when multiple updates exist? ☐ Can the app be downloaded on multiple operating systems? ☐ Can the app be redownloaded? ☐ Does…More