teardownを探していたのですが、 ExUnit では、現在はteardownは on_exit のcallbackで実装されています。過去、この形に変更されたのですね。 http://elixir-lang.org/docs/v1.1/ex_unit/ExUnit.Callbacks.html#on_exit/2 使い方は以下。 setup の中で on_exit を定義します。これで、この setup_all や setup と同じサイクルで処理が実施されます。 ちなみに、 shouldi を使った時は上手く動作しなかった… 過去、私も書いていた… MIX AND OTP vol 1More
Category Archives: software test
SQuBOK読破会で紹介された書籍たち
『SQuBOKv2読破会 Advent Calendar 2015』、21日目の記事です。 この読破会では、毎回、各々が約1ヶ月間の間に読んだ書籍などを手短に紹介する、というちょっとした取り組みを導入をしてました。その内容はFacebookページで共有され、ざっと眺めると76コメントつくほどまでになってました。その多くにURLが貼っており、それらをたどることができる状態になっていたのでそれらを並べてみました。下の方に並べています。ご覧ください。 全部で76個ではないのは、Facebookページからスクレイピングで一括でURLを取得したので一部欠如が発生してしまったことや、コメントだけのところもあるためです。(横着してすみません。。。) 読み物から、技術書まで、いずれも1ヶ月でサクッとできるものから、できないものまで。多種多様な書籍が約1年かけて集まったと思います。それらをソフトウェアテスト、ソフトウェア開発、デザイン、そのほかという感じで分けてみました。眺めるとちょっと雑ですね… ただ、こう眺めるだけでも様々な書籍が読まれていることがわかります。SQuBOKがソフトウェア品質を扱うものであるように、ソフトウェア品質とは単にテストといった狭い視野ではなく、ソフトウェア開発全体やその周辺・人の興味に至るまでの様々な要素が絡んでいる、というところにもつながりを感じて面白いですね。 私の中でも、ほかの人が紹介する書籍にはすでに読んだことのある書籍、しっているけれど読んだことのない書籍、知りさえしなかった書籍などあり、多様な出会いがありました。ほかのメンバも同様にそのような出会いがあったことでしょう。 個人的にお勧めなのは アンティキテラ 古代ギリシアのコンピュータ です。これは、最古のコンピュータと呼ばれている歯車式の計算機が古代ギリシャに存在していた、というところに至るまでの軌跡を描いています。そこに関係した様々な人の関わりなどもあり、SFのようにも読むこともできます。なお、まだ現在も調査は実施されていて完全に解明されたわけではないようです。 知っていることが多いと、それだけ思考を狭めて創造的な考えができなくなることがあります。そして、それは私が大学時代に教授からよく言われていることでもあります。ただ、何か創造的な考えを行うために、ほかの既知の領域ではすでに知られていることに頼る、創造的な考えを行うための下支えとして書籍などに学ぶ、というのは私はありだと考えています。 書籍に限らず、頼り頼られつつ、何かやりたいことに集中できる環境を創造できるとよいですね。 Software Test Test Maturity Model integration ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 実践 JUnit ―達人プログラマーのユニットテスト技法 Bug Advocacy: A Bbst Workbook つながる世界のソフトウェア品質ガイド ~あたらしい価値提供のための品質モデル活用のすすめ~ I am a Bug ソフトウェア・テスト PRESS Vol.10 ISTQB関連 JSTQB関連 Making Software ―エビデンスが変えるソフトウェア開発 落穂拾い (1966年) Software Development ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系 ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0 7つの言語 7つの世界 オブジェクト指向入門…More
[Android]Espresso for AdapterView
Espressoは通常、 onView(mathers) によってビューの取得を行います。一方で、 Adapterview 系のレイアウトでは、レイアウトの要素は実行時に動的に作られます。その場合、 onView では、その動的に作られた要素をちゃんと取得することができないようです。 その場合は、 onData が提供されているので、それを使うことで代替します。 参考: https://developer.android.com/intl/ja/tools/testing-support-library/index.html ちなみに、 android.support.test.espresso.contrib がespresso-core以外でライブラリとして提供されているのですが、そこでは RecyclerViewActions が定義されています。中を読んでみると、このViewは onView で要素を取得して、それに対してactionしてねと書いてます。なるほど。 http://developer.android.com/intl/ja/reference/android/support/test/espresso/contrib/RecyclerViewActions.html 少し凝った使い方は公式でも用意されているので、参考になるかもしれません。 https://google.github.io/android-testing-support-library/docs/espresso/advanced/index.htmlMore
[Elixir]about parameterized test with Elixir(Eng ver)
Previously, I published support library to do parameterized test with Elixir on hex and WordPress. See here, but it in Japanese. The library is simple macro. So, anyone can use it easily. See readme and docs if you would like to know more hex https://hex.pm/packages/ex_parameterized GitHub https://github.com/KazuCocoa/ex_parameterized Example This file contains hidden or bidirectional Unicode…More
SQuBOKとそこから見える人
『SQuBOKv2読破会 Advent Calendar 2015』、14日目の記事です。 前回、私は『SQuBOKv2読破会と私』ということでこの読破会に参加して得たこと、役立ったことなどの、私自身の周りの話を書きました。 今回は少し趣向を変えて、SQuBOKを読んでいたときに感じたその書き手について書いてみます。SQuBOKは複数の人によって書かれ、レビューされ、洗練されました。そのため、複数人の書き手が関わっています。 私は書いているかた全員をしっているわけでもありません。また、誰がどこを書いたのか、ということもよく知らない、という前提があることはまず記載しておきます。 抽象的なまとめのうまさ 全体的に、適度な抽象度を保っていたことが素直に素晴らしいと感じました。適度な抽象度とは、経験からしても納得できることだし、未経験なことでも十分に想像につなげることができる範囲でうまくまとまっている、ということを指します。 こういう書籍は、時代によってすぐ陳腐化する表層的な話と、長年親しまれる深い話があります。表層的なものはそのときのはやりのツールや言葉を使ったものが多いです。一方、深い話はより人や組織につながるもの、考え方の基幹をなすものです。 書籍の良い点として、様々なレビューを繰り返しながらも1つの集大成に仕上げる工程があることでしょうか。今のところ、Webサイト上ではなかなか構築されない洗練度のものです。このSQuBOKもその例にもれず、様々な知見を持った方々が、頭をひねりながら作り上げた力作と感じるよな内容でした。 所々、表層的 一方で、v2ということもありv1を元に加筆・修正した箇所があります。私はv1はちゃんと読んだことはないので、その差分が明確にはわかっていません。ただ、書籍を読んでいるとここは加筆されただろうな、というところが見えてきます。良くも悪くも、時代が反映されている感じで。 いくつかの場所は、ほかの場所に比べて些か表層的な説明が多いです。つまり、その時代固有の言葉が表現の至るところに見えます。具体的なツールやサービスの名前であったり、1年後はまるっと変わっている、古くなっている可能性のある要素です。確かに、ここ数年を振り返っても特筆しておくことには価値があると思います。ただ、そういう内容はBOK系ではなく、通常の書籍などでもよかったかもしれません。そんな感触を受けるところもありました。 熱の入った表現 通常、BOK系は技術書的な読み物なことが多いです。ただ、Software Quality / Test関係は、人の営みが多分に関係する分野でもあります。そのため、人の改善プロセスといった人に寄り添う内容が中心に添えられている箇所も多分にあります。その箇所は、書いている人の色もあると思うのですが、比較的熱のこもった表現が散見されました。 締め 書き手を楽しむ、というのは、まるで小説を楽しむかのように見えるかもしれません。私は、通常は技術書はそんなに書き手の書き方を気にすることはありません。ただ、このSQuBOKは所々個性が感じられて、小説まではいかなくとも、書き手を楽しむこともできました。 普段何も考えずに触れるものも、少し違った視点でふれると違った面白みがありますね。 少し短いまとめとなりましたが、また。More
SQuBOKv2読破会と私
最近開いたTestingに関するイベントを行ってから、感じること、気づくこと、つながりといったところを考えるこの頃です。 さて、SQuBOKv2読破会 Advent Calendar 2015、5日目の記事です。4日目はSQuBOKによる無知の知の体験でした。 この会は、有志何人かが集まってソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)を読み、議論し、より良いソフトウェアを創造していくための足がかりを得るものです。そこら辺の概要は1日目の記事を参考にすると良いでしょう。 この本自体はより良いソフトウェア開発を対象とした、組織的な大局話からプロジェクト個々の話、コード品質やテスト技術と局所的な話に至るまでの全般な話を扱っています。コードの実装やテスト実施などの実施の時代によって移り変わりが激しいところは適度に抽象化されて、時代に流れすぎない形でまとめられています。 今回は、この読破会と私、ということで少し書きます。 きっかけ 私は過去、WACATEと呼ばれるソフトウェアテストに関わる人たちの集まりに参加しました。2014年の冬でしょうか。その頃、夜の分科会を(確か)テストエンジニアのこれから、という少しざっくりとした話題で開かせて頂きました。その時に色々話をしました中にいた、@masskanekoに誘われる形で参加しました。 当時、SQuBOKv2は軽く読んでいました。ただ、やはり量が多いので個々の要素は詳しく読んではいませんでした。自分の必要な箇所だけかいつまんで読む、それ以外はこれから必要になったときに時折読む、という感じでした。 そんな折、この読破会への誘いを受けました。結果、一人で読んで積読に近いものになるよりは良いかな、という気持ちで参加してみました。 参加して SQuBOKは知識体系と言われますが、実態は 困った時に過去の経験を素早く参考にすることが可能な indexのようなものです。内容の情報量からしてもそうは思っていたのですが、この会で読んでその認識がさらに強くなりました。この過去の経験、というのは1990年代の産業が成長し始めている頃からの様々なトライアンドエラーの塊です。 例えば、Web界隈では最近開発プロセスの変化や組織の移り変わりの話など含めてマネジメントの話、プロセス改善の話をよく聞きます。そのあたりは、小さな個人の開発からチーム/組織な開発に業界全体が遷移しようとしている時代だからであったり、はたまたスタートアップが増えているからでしょう。そこでよくある改善の取り組みやアンチパターンなんかは、私の経験と照らし合わせてもこのSQuBOKに同様なことがすでにまとめられていました。(マネジメント特化、などになるとまた話が変わりますが。) 失敗するよくある形、それを防ぐために先人はどのような取り組みを行ったのか、というものをざっと知ることができました。その具体は時代や周辺環境に差があるので全く同じではない、というのは自明です。それを踏まえた上でも、やはり役立ちます。 手段としてのツールや環境は変わろうとも、人による創造的な取り組み自体は今も昔も大差ない、ということのようですね。そこら辺の取り組みが巨大化・形骸化して今に至ったのだとしても、前を向いて前進していた熱い時代では変わらぬ改善への取り組みを行っていたようですね。ここら辺は大学時代に教授らから話を聞いてはいましたが、改めてなるほどねーという感じでした。 合宿 開発者の中には開発合宿を開いたこともあると思います。それと違わず、この読破会も同様な合宿を夏頃に行いました。ただ、開発者合宿でよくあるプログライングが伴うものではありません。 ソフトウェアメトリクスなどの、ソフトウェア製品自体の計測をどうするか、どんな研究があるか、というところを話題の中心に、色々議論していました。参加した人たちの経験などを色々議論しつつ、非公開な情報を共有したりと、本だけでは得られない知見を得られました。 アルコールや温泉などは言わずもがな 、です。 今生かされていること これらの経験は、今の実際の業務に生きています。 例えば、私は立場上プロセス改善などを主導する位置にもいます。また、チーム作り、採用などの先も考える必要もあります。そのような組織に寄った活動を日々のそれなりに多忙な開発実務と並行して行うには、経験が全てではやっていけません。(少なくとも私は無理そう)。そのような時、直接的な解答をあたえてくれることは少ないですが、それにつながる過去の事例を提供してくれる体系はとても役立ちます。 少なからず私たちが進めようとしていることに対してよくない匂いに気づくアンテナを広げることにも役立っています。取り組んでいることがハズレではないこと、不安なら参考になりそうな過去の経験へのアクセス手段までたどり着けることがわかっていることは、行う取り組みに対して背中を後押ししてくれます。 開発言語やそれらを取り巻くツールのように動きの早いもの、人に関する古くから研究されていて動きの穏やかなもの、それぞれを上手い具合に取り入れながら活動を継続したいですね。 最後に 今の自分、環境は特別である。過去の先人とはまったく違う。 こういう思想を持っていない人にとっては、SQuBOKのような体系はなんらかの形で恩恵を読者にあたえてくれると思います。これは新規サービス開発といったサービス自体の話ではありません。すでに研究され続けている人の関わる系に関する話です。 この書籍に限りませんが、よくある失敗として目的と手段のはきちがいがあります。また、前例にとらわれて思考が停止してしまうこともよくあるでしょう。そこに言及することは不毛なので立ち入りませんが、一応注意点としては残しておきます。 では、手短な内容となりましたが以上になります。次回は 吉田東京 さんです。引き続き宜しくお願いします!More
[Swift]UI Testing Failure – Multiple matches found
XCUITestでは、例えば以下のように記述することで、button要素に “example” とtitle/accessibilityIdentifierなどが付与されたものを取得、tapします。 ただし、表示されている画面要素に対して、この条件に合致する要素が複数存在した場合、以下のようにエラーが表示されてテストがこけます。 UI Testing Failure – Multiple matches found こんな時は、以下のように elementBoundByIndex を使うことで、特定の配列要素を得ることができます。( childrenMatchingType(.Button) はオマケ ) 例えば、Appium x ruby_libを使った場合は複数要素を取得する場合は配列で要素が得られます。なので、そこらへんを使ったことがある人だとSwiftでも配列として得られて、 XCUIApplication().buttons[“example”][0].tap() とかでできそうな気がしますが、そでは正しく動作しません。 elementBoundByIndex を使わないといけないのですね。 なるほど。 ここら辺、ソースコードと睨めっこな領域になるのですが、だいぶどんな感じのメソッドがあるのか把握してきた感じ。More
[Swift]parameterized test with Swift
When we describe test cases with similar parameters, we do parameterized test . In Swift, I can’t find library to do it. So, I consider how to do parameterized test with Swift. Here is a sample for it. This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what…More
[Swift]SwiftでParameterized Test?
Swift2.1でParameterized Testをどう書こうか、と考えた時、以下な感じでできそうに思えたのでメモ。 parametarized() にBlockとデータセットを与えることで、そのBlockの中の要素を全てBlockにて与えた処理を行う 与えるパラメータは、 struct で定義する 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 import XCTest class xctestSampleTests: XCTestCase { //…More
[iOS][Swift]XCTestでパフォーマンスを計測したり、処理をwaitする
XCUITestでテストを行う時、アニメーションの都合で処理をまったり、突然の性能劣化がないか、ということを計測することの重要性が高くなります。 そこで、XCTestを使ってそれらを実現する方法を最近調べたのでメモ。 処理性能を計測する ある範囲の処理の処理性能を計測したい場合があります。 XCTestでは、以下の通り measureMetrics を使って、与えたブロック内の処理を計測、一定の性能劣化があった場合にfailしてくれる機能があります。 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 func testShouldDisplayAlertWithText(){ // run 10 times and…More