ランダムにおちるfeature/system specへの対応とリトライ機構 - ENECHANGE Developer Blog
背景 プラットフォーム事業部のtaki（@yuyasat）です。ENECHANGE社には2016年10月から参画し、主にRuby on RailsやJavaScriptまわりの実装を行っています。 ENECHANGE社の顔とも言えるサービスが、電気・ガス比較サイト エネチェンジです。WordpressとRailsでできており、リポジトリのfirst commitから４年以上が経過しています。確認したところ、first commitはCTOの白木で、2014年5月16日でした。会社の設立が2015年4月ですから、会社の歴史よりも長い歴史をもつリポジトリということになります。ENECHANGE社の前身はCambridge Energy Data Labで、その当時に開発が開始されたわけです。 そんな４年以上の歴史を持つリポジトリですが、機能も増え、申し込み可能な電力会社も増えてきており、それに
rspec-retryでfeature specを安定させる - しめ鯖日記
rspec-retryという、失敗したテストを再実行するGemを使ってみました。 GitHub - NoRedInk/rspec-retry: retry randomly failing rspec example まずはRailsのプロジェクトを作ってfeature specを書きます。 require 'rails_helper' feature 'test' do scenario 'ページが表示される' do visit users_path expect(current_path).to eq users_path end end ここに一回目だけ失敗する処理を追加します。 require 'rails_helper' i = 0 feature 'test' do scenario 'ページが表示される' do i += 1 raise if i == 1 visit use
Feature Specで複数ユーザーのやりとり(マルチセッション)をテストする - 弥生開発者ブログ
はじめに インターンのhmryuです。今週、Misocaのインターンを卒業しました。僕は、昨年のお盆明けから約7ヶ月間Misocaでエンジニアとして働いていました。とくに後半の4ヶ月は、発注機能の開発に関わっていました。 現在の発注機能では、複数のユーザーがコメントのやりとりやファイル共有を経て、発注できるしくみになっています。 もともと、発注機能のFeature Specでは、コメントや発注などを別々のsenarioで書いていましたが、それだと不必要に冗長な部分が増えてしまいコードの修正が難しくなっていました。そこで、1つのscenarioで発注機能全体をテストできるように大幅な修正を行いました。 (Controller Specについては、ミニマムリリースを意識していたらコードが肥大化していた話にまとめてあります。) マルチセッションのFeature Spec そこで問題になったのは、
Read Everyday Rails - RSpecによるRailsテスト入門 | Leanpub
この版のまえがき 改訂版の「Everyday Rails - RSpecによるRailsテスト入門」を手にとっていただき、どうもありがとうございます。改訂版をリリースするまで、長い時間がかかりました。そして、内容も大きく変わりました。本書を読んだみなさんに「長い間待った甲斐があった」と思っていただけると幸いです。 なぜこんなに時間がかかったのでしょうか？前述のとおり、内容は大きく変わりました。本の内容そのものも変わりましたし、Railsにおける一般的なテストの考え方も変わっています。まず後者について説明しましょう。Rails 5.0の登場と同時に、Railsチームはコントローラのテストを事実上非推奨としました。個人的にこれは素晴らしいニュースでした。本書の前の版では説明に 3章 も使っていましたが、私も最初はコントローラのテストを理解するのに非常に苦労したのを思い出しました。そして、最近で
【Rails】APIテストの書き方 - Qiita
概要 Railsで作成されたAPIのテストについてこちらを参考に必要最低限の情報をまとめました。 実際にこちらの記事で作成したAPIに対してテストを書いていきます。 何をテストする？ 適切なAPIはHTTPのレスポンスのステータスコードと実際のデータを含んだレスポンスボディを返します。 よって主にその２つをテストしていきます。 ステータスコード 通常APIによって返されるステータスコードは以下の４つに分類されます。 APIの動きによってこちらのコードと照らし合わせる事でテストします。 200: OK - リクエストは成功し、レスポンスとともに要求に応じた情報が返される。 401: Unauthorized - 認証失敗。認証が必要である。 403: Forbidden - 禁止されている。リソースにアクセスすることを拒否された。 404: Not Found - 未検出。リソースが見つから
RSpecのベストプラクティス集（Better Specs）の日本語まとめ - Qiita
[5/1追記]日本語版あったようですorz Better Specs Better Specsから項目と簡単な説明をピックアップしています。 何点か似てるのあったのでマージしてます。 テストコードの書き方 describeでは対象メソッド名を明確にして、文章も短くしよっ describeは長々文章で書くと読みにくいよ メソッド名で簡潔に表現してね # .はクラスメソッド、#はインスタンスメソッド describe '.authenticate' do describe '#admin?' do
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
