RSepcをつかったModelとControllerの基本的な(ユニット)テストは、 なんとか書けるようになってきましたが、 「ちゃんとテストやれてる！」 と言えるにはまだまだ、 インテグレーションテスト エンドツーエンドテスト 受け入れテスト 色々とやれることはあります。 直近、ユーザーのアクションがより重要なサービスの開発を進めることもあり、 「エンドツーエンドテスト」をやれる良さ気な方法は何か調べてみて、動くまでをまとめてみした。 ※結論からいうと、「RSpec ☓ Capybara ☓ Poltergeist」で書くことにした記事です。 目次 過去記事(RSpec設定/MCtest) E2Eテストに何が必要？ シナリオ(ステップ)を書くのはどれがいい？ js動作のドライブはどれがいいの？ E2Eの環境セットアップ方法は？ feature specの書き方は？ おわりに 過去記事 ※
はじめに 2014年7月8日の晩に、ソニックガーデンのweb勉強会であるSonicGarden Studyで、「CodeIQ ベストコード発表会 ～最もエレガントにカラオケマシン問題を解いた挑戦者は誰だ！？～」を放送しました。 http://sonicgarden.doorkeeper.jp/events/12901 今回のエントリはこの放送の内容を簡単にまとめておきます。 放送に使ったスライド 放送で使ったスライドはSlideShareに置いてあります。 CodeIQベストコード発表会 #sg_study from Junichi Ito 放送の録画 放送内容は録画してYouTubeにアップしました。 1時間20分ぐらいあるのでちょっと長めです。 CodeIQ ベストコード発表会 ～最もエレガントにカラオケマシン問題を解いた挑戦者は誰だ！？～ 「カラオケマシン問題」ってどんな問題？ カラ
Photo by Flickr: chief_huddleston's Photostream Railsの規模が大きくなると自動テストの実行時間もだんだんと長くなっていきます。素早く開発していくにはテストの実行時間を短くすることが大切です。 RSpecのテストを速くする方法をまとめましたので参考にしてください。 動作確認 Rails 4.1 rspec-rails 3.1.0 test-queue 0.2.9 目次 1. RSpecのパフォーマンス測定 2. test-queueで並列でテストを実行する 3. rspec-guardを使って更新したファイルを自動的にテストする 4. Springを使ってテストのロード時間を短くする 5. ログレベルを変える 6. GCを実行を抑える 7. RSpecファイルのリファクタリングをする 7.1. itを少なくする 7.2. createよりも
What is Better Specs Better Specs is a collection of best practices developers learned while testing apps that you can use to improve your coding skills, or simply for inspiration. Better Specs came to life at Lelylan (open source IoT cloud platform) and checking out its test suite may be of inspiration. Better Specs focus on Rails testing, but our goal is to create testing guidelines covering mos
タイトル長い。すまぬ。PHPerとして約10年近く。Ruby自体は案件によってちょこっとだけ触ったことがある程度。Rails自体を本格的にさわるのは今回が初めて。PHPだとCakePHPを中心にZend／Symfonyなどいくつか。そんな僕が今回、Rails4デビューをして、WebAPIを作り、RSpecでテスト駆動開発風味で、GitHubプルリクベースの、CircleCI経由デプロイをするまでの開発の流れをひと通りやってみて、分かったことがいくつかあったので、それをまとめてみた。過去の自分のために。 注意点としては、今回作ったのはWebサービスではなく、スマホゲーム（ネイティブ）のサーバサイドWebAPIという点。なので、いわゆるViewに関わる部分はあんまり出てこないです。すまぬ。 それと、ひと通りの流れをチュートリアル的に解説するような記事ではなく、躓いたポイントだったり、当時分かり
Myron Marston » New in RSpec 3: Composable Matchersの訳です。 あかんところあったらTwitterで@nilp_までお願いします RSpec 3の、最も大きな新機能が3.0.0.beta2で公開されました: コンポーザブルマッチャ(組み合わせ可能なマッチャー)です。 これにより強力で壊れづらい検証を書けるようになり、新たな可能性が開けました。 例 RSpec 2.xでは、私はこのようなコードを度々書いてきました。 class BackgroundWorker attr_reader :queue def initialize @queue = [] end def enqueue(job_data) queue << job_data.merge(:enqueued_at => Time.now) end end describe Back
ログインして、販売伝票ボタンを押し、商品追加ボタンを押し、表示された商品ページでカテゴリーを選択し、商品の一覧を表示し選択ボタンを押し・・・ ・・・ ・・・ 確定ボタンを押す。 のようなたくさんの手順で一つの作業が完結するようなWebアプリの受け入れテスト(顧客テスト、総合テスト…)を RSpec + Capybara の Feature specs を使って書いてみました。 通常このようなテストには Cucumber や Turnip が使われる事が多いですが、どちらも feature(テスト記述) と sptep(コード)に分かれていています。 顧客や開発者以外の人が feature の作成やレビューに関わる場合はメリットがありますが、開発者だけがテストに関わる場合は面倒なだけです。 そこでプログラマーの大好きな RSpec だけで、受け入れテストを書ける Feature specs
RSpec の書き方について 要約:RSpec は単なるテストを英語っぽく書けるツールではなく開発の全プロセスを加速するツールであるのでプロジェクト初期から有効に利用する必要がある。 4/1 ですが気にせず真面目な話を書きます。 RSpec は多分 Ruby 界隈で一番使われているテストフレームワークの一つだと思います。であるので使い方の解説や概念の解説多いですが、個人的にはそれらの解説は的を外したものが多いと考えています。 RSpec の真髄を会得するには、 RSpec の spec をどのように書くかということを考えてゆく必要があると思います。 まず RSpec の特徴的な点とはなんでしょうか。 RSpec でテストは以下のように書かれます。 describe "肛門" do context "排便する時" do it "高速に排便されると肛門がすりきれる" do 肛門がすりきれるとい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く