I released http_proxy 0.3.0 which support play/record http request. Now, the library support multiple port proxy and each proxies support play/record request. Hex: https://hex.pm/packages/http_proxy Docs: http://hexdocs.pm/http_proxy/0.3.0/extra-api-reference.html GitHub: https://github.com/KazuCocoa/http_proxyMore
Author Archives: KazuCocoa
『7つの言語 7つの世界』を読んだ
『7つの言語 7つの世界』を読みました。電子書籍は、このeBook StoreのWebサイトから購入しました。ちょうどeBook Storeのリニューアルキャンペーンで安く購入できるようになったので、これを機に読んでみることにしました。 取り上げられた言語が開発された背景、概念、目指すものなどがうまいことまとめられています。また、それらが解決したいとしていた問題など含めて。 私は言語仕様自体ではなく、それらが解決したいとしていた現実問題やその成長の歴史を学び、現実の問題にフィードバックを与えることに興味があります。そういう意味で、私がこの本に興味を持ったのはちょうどよかったです。 取り上げられている言語は以下。これらに絞った理由などはこの本書に書かれているのでここでは除きます。 Ruby Io Prolog Scala Erlang Clojure Haskell 私はRuby/Scala/Erlangはある程度触ったことがありました。Ioは唯一、初めて見聞きしたものでした。他は聞いたことはあるけれどまだ踏み込んでいないものです。それらの概要や基本的な書き方、特徴的な箇所をざっと知り、それらの成長の課程を学ぶことは読み物としても興味深いものでした。 読んでいて、例えばElixirの言語設計にClojureに影響されたと書かれている箇所が多分にあるのですが、そこの影響された箇所がわかったりしてなかなかに面白かったです。Haskellのモナドなんかは、写像とか、そういう言葉は理解できるけれどそれがプログラミング言語としてどう現実解に落とされているかぱっときてませんでした。そこへの取っ掛かりも得ることができました。 こういうプログラミング言語などの発展は、やはり解決したい問題とこれまでの蓄積があるのですね。 あと、この本で楽しかったのが各言語がなんらかの物語に照らし合わされていたことです。例えばErlangは映画・マトリックスの世界で語られていました。Haskellはスタートレックのスポックなど。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
『エンジニアとして世界の最前線で働く選択肢』を読んだ
『エンジニアとして世界の最前線で働く選択肢』を読みました。 海外で働くというよりは、日本人という特性がマイノリティになる場で働くことに対して、はたまたコンピュータサイエンスを求める求人に対して考えることができる面白い書籍でした。 採用におけるプログラミングやアルゴリズムの話など、いくつか大学時代に学んだことが書かれていました。今でもパッと思いつくだけ、大学の頃に学んだことは役立っている、ということですかね。 これを読んで、何を思ってか簡単なbinary searchをElixirで実装してみました。 [Elixir]implement binary search with Elixir この書籍はプログラマを主な対象としていましたが、テストエンジニアも多分これで求められることはあまり大差はなさそうと感じています。なんというか、コンピュータサイエンスを学んでいたら基礎としてある程度学ぶであろうことなので。そこからさらに、プログラマとしてのセンスなんかが効いてくるのでしょうね。 そうそう。この書籍に、まだ慣れない環境で周りの人と仲良くなるにはランチなどの食事の時間が大事、というのがありました。食やそれを取り巻く環境、作って誰かに/誰かと食べて適当に話す環境、それはやっぱり重要なんだなと感じた日でした。More
[Elixir]implement binary search with Elixir
ElixirでBinary Searchを実装してみた。メモ。 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 defmodule Search do def binary(_, []), do: -1 def binary(search, [head|tail]) when…More
[Swift]XCUITestにおけるCoverageとScreenshotの在り処
XCUITestでは、自動的にスクリーンショットを取得してくれます。それがどこに保存されるか?というと、以下のように Attachments に保存されました。保存されるファイル名に統一感がないのですが、 plist にテストケースとスクショの結びつけを保存しているのですね。テスト結果をXcode以外からうまいこと見ることできないかなーと思ってたのですが、すんなりホイとはできなさそうな感じです。 /Users/user-name/Library/Developer/Xcode/DerivedData/TestProject-randome-values/Logs/Test/Attachments あと、スクショのタイミングを任意なタイミングではできないので画像比較のためにそれを使う、というのには使えなさそうな感じです。んー。テスト失敗した時の参考になる以上ではちょっと使いにくい感じです。 ついでに、XCUITestでも、カバレッジを取得できる模様?ちゃんと計測はしていないのですが、うまいこと使えれば使えそうでした。 そのほか XCUITest、いろいろ調べてみましたが通知のダイアログなどのシステム設定をリセットする手段ないので、ちょっとテストケースの管理に難しさを感じました。 ちなみに、wait/sleepは適度にwaitしてくれるので、さほど気にしすぎなくても良いのですね。 waitUntil のようなメソッドを定義したのですが、それを使うのは限定的になりそう。retryが内包されているのはGUIから操作するテストケースではありですね。Exceptionを出す種類も、 XCTAssert 系以外にもいくつかあったのですが、ここはXCTestの頃からそのまま使っているもののようですね。 このfastlaneのsnapshotも、このXcode7(XCUITest)対応したみたいですね。 https://github.com/fastlane/snapshotMore
[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
[Swift]The Swift Programming Language(Swift2.1)を読んで写経して学んだ
主に、Language Guideの箇所を全て読んで、写経して学びました。Swift2.0になって段階になったと周りから聞いたし、色々と本格的に関わる必要がでてきたので、ですね。 iBookで読んだのですが、HTMLでもあるのですね。こちらから参照することができました。 基礎的な言語仕様を写経しながら学んだので、OS提供のAPIに沿って何か開発できるところまではまだやってません。ただ、Test Engineerとしては言語仕様側をある程度知っておくことは入り口として必要なのでこちらから踏み入ってたりします。 Swiftは Class は参照型(reference type)、 enum や struct は値渡し(always copied)なのですね。なるほど。 Because classes are reference types, it is possible for multiple constants and variables to refer to the same single instance of a class behind the scenes. (The same is not true for structures and enumerations, because they are always copied when…More