RubyでPageObjectsパターンを実装できる SitePrism のご紹介 - Qiita
この記事はSelenium/Appium Advent Calendar 2016の10日目の記事です。 はじめに freee株式会社でアプリエンジニアをしている @kompiro と申します。普段は selenium をガリガリ動かしているエンジニアではないのですが、SitePrism というgemを使って PageObjects パターンを実装してみたら、想像以上に捗ったのでご紹介します。 SitePrism の特徴 SitePrism とは PageObjectパターンをCapybaraを使って実装するためのDSL です。 例えば google.com のページオブジェクトを SitePrism を使って定義すると下記のようになります。 # Pageの定義 class Home < SitePrism::Page set_url 'http://google.com' element
Gunosyの広告管理画面を支えるE2Eテスト - Gunosy Tech Blog
広告技術部のサンドバーグと星です。 普段の業務は、主に広告の管理システムの開発をしています。管理画面はRuby on Railsで作られており、今回は煩雑になりがちなE2Eのテストをきれいに書けたので、それについて話します。 背景 Gunosyの広告システムは4年以上前にリリースされ、これまで多くの機能が追加されてきました。 配信システムは一度リプレースされましたが、私達が運用している管理画面に関してはリプレース などはされず、現在も拡張され続けています。長く運用されているシステムのため 開発するメンバーの入れ替わりもあり、もちろん思想やコードスタイルも変わってきたため、 バグが発生しやすい環境になってしまっています。 ただ、外部のお客様も使う機能も含まれるため、バグが無いことを担保する必要があり、 テストがより重要になってきます。 また、複雑なデータ構造と画面操作があるため、単体テストで
RSpec/Capybaraのテストコードを画面操作から出力するChrome拡張をつくった - memo_md
ほぼ表題の通りの内容で、Chrome拡張を作ってみた。 完成度としてはまだまだだけど、とりあえずざっくり触れる程度にはなったので公開した。 github.com chrome.google.com アイコン画像は、カピバラの写真を適当になぞって作った。 なんでこんなものを？ Capybaraのテストコードを書くのが面倒だなって感じることが多かったのが1つの理由。 TDD的に、先にテストコードを書いていけるのが理想だな〜とは思うものの、Webアプリケーションの開発をしていると、現実には一度は画面から一通り確認して、その後にfeature specを書く流れが多いように感じる。 そしてCapybaraでfeature specを書こうと思うと、 「これはテキストじゃなくてIDで選択しないとダメか〜」 「あ〜、これはfindしてからsetしないといけないのか〜」 という感じで、スムーズに書けない
Feature Specで複数ユーザーのやりとり(マルチセッション)をテストする - 弥生開発者ブログ
はじめに インターンのhmryuです。今週、Misocaのインターンを卒業しました。僕は、昨年のお盆明けから約7ヶ月間Misocaでエンジニアとして働いていました。とくに後半の4ヶ月は、発注機能の開発に関わっていました。 現在の発注機能では、複数のユーザーがコメントのやりとりやファイル共有を経て、発注できるしくみになっています。 もともと、発注機能のFeature Specでは、コメントや発注などを別々のsenarioで書いていましたが、それだと不必要に冗長な部分が増えてしまいコードの修正が難しくなっていました。そこで、1つのscenarioで発注機能全体をテストできるように大幅な修正を行いました。 (Controller Specについては、ミニマムリリースを意識していたらコードが肥大化していた話にまとめてあります。) マルチセッションのFeature Spec そこで問題になったのは、
Capybaraを使う際に知っておきたいこと - Qiita
defaultは? defaultではRackTestが使用されていて、高速だしRubyで書かれているのでRuby以外に依存してるソフトウェアが無くて良いのですが、JSが実行出来ませんし外部APIとかも叩けません。 個人的な意見としてはJS実行、外部APIを叩くことが必要でなければRackTestのままでいいと思います。 JS実行や外部APIを叩きたければ? こうなるとheadlessではないSelenuimか、headless driverであるCapybara-webkitやPoltergeistになってきます。 まず、headlessではないdriverを選んでしまうとテスト実行毎にブラウザが立ち上がってしまいます。これは鬱陶しいのでメインで使うには不適当です。 ということでheadless driverであるCapybara-webkitやPoltergeistになってきます。 最
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
