ほぼ表題の通りの内容で、Chrome拡張を作ってみた。 完成度としてはまだまだだけど、とりあえずざっくり触れる程度にはなったので公開した。 github.com chrome.google.com アイコン画像は、カピバラの写真を適当になぞって作った。 なんでこんなものを？ Capybaraのテストコードを書くのが面倒だなって感じることが多かったのが1つの理由。 TDD的に、先にテストコードを書いていけるのが理想だな〜とは思うものの、Webアプリケーションの開発をしていると、現実には一度は画面から一通り確認して、その後にfeature specを書く流れが多いように感じる。 そしてCapybaraでfeature specを書こうと思うと、 「これはテキストじゃなくてIDで選択しないとダメか〜」 「あ〜、これはfindしてからsetしないといけないのか〜」 という感じで、スムーズに書けない
概要 画面操作とテストシナリオが疎結合にできるPageObjectデザインパターンを試したかったので、検索ワードにヒットする商品を自動購入するAmazonの自動購入処理を書きました。 参考ページをCapybaraに移植したものになります。 PageObjectデザインパターンとは 公式によるとPageObjectデザインパターンとは、以下だそうです。 ・The public methods represent the services that the page offers（publicメソッドは、ページが提供するサービスを表す） ・Try not to expose the the internals of the page （ページの内部を公開しないこと） ・Generally don’t make assertions （原則としてassertionを行わないこと） ・Method
Selenium + Capybara + RSpecで自動テストしてみる : 準備編Sun, 27 Nov 2016 06:02:34 GMTテスト Ruby Selenium RSpec Capybara 前回の記事でSelenium + Rubyでテストを始めてみるも 「これってブラウザの操作はできたけど、どのテストが通ったのかわからないんじゃね？」 と気づきました。その結果、タイトルの組み合わせでテストすることにしました。 2017/1/28 追記 この後にもいろいろやったんですけど、結局RSpecを使わずにMinitestに変更しました。 前書き CapybaraはSelenium（というかRubyのその他も含めたテスト関連の）ラッパーのようです。RSpecはRubyのテストフレームワークです。 なお、どのテストが通ったかどうか判断するだけだとCapybaraはいらないですが、生
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
一休.com宿泊サイトのE2Eテスト事情をギッリギリまで話しました。このスライドを見た方は一休のエンジニアより一休のE2Eに詳しくなると自負しております。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
