こんにちは、sunflat です。最近プライムビデオが始まったので、24とごちうさ第１期を見始めました。
Misocaのプロジェクトでは、rspecによる自動テストを行っています。 今回は、rspecの機能拡張である rspec-retry というgemのリポジトリに、Pull Request を送ってマージしてもらえた話を書きます。
rspec-retry とは
rspec-retry を使うと、spec（rspecで実行されるテスト）のexample（テスト項目）が失敗した時に、再度そのexampleを実行（リトライ）することにより、確率的に失敗するspecの失敗確率を低下させることができます。
Misocaのspecの中には、capybaraを使い、ブラウザの挙動をシミュレーションして統合テストを行うものがあります。capybaraを使ったspecのいくつかは、実行されるタイミング等によって、まれに失敗することがあります。
Misocaのプロジェクトでは、デフォルトのリトライ回数（default_retry_count）を2回に設定しています。
解決する問題
capybaraを使ったspecの実行には時間がかかるため、失敗するspecを実行する場合（specをデバッグする時や、BDDをする時など）に、rspec-retryによるリトライが発生すると、結果が分かるまでに時間がかかるのが問題です。
rspec_retry によく似た rspec_rerun というgemでは、環境変数RSPEC_RERUN_RETRY_COUNTを設定することにより、このリトライ回数を上書き変更することができます。
リトライ回数を制限して実行を速くする
Misocaで使っている rspec_retry にはこの機能がなかったので、rspec_rerunの場合と同様に、環境変数RSPEC_RETRY_RETRY_COUNTを設定してリトライ回数を上書き変更できるようにしました。
失敗しそうなspecを実行したい場合に、環境変数を RSPEC_RETRY_RETRY_COUNT=1 と設定しておくことにより、一時的にリトライを抑制することができます。
これにより、必要に応じて素早く結果を得ることができます。（といっても、例えば今回の実行例の場合、40秒ぐらいかかるものが30秒ぐらいになる程度なので、劇的な短縮という訳ではありませんが）
Pull Request を送る
最初は、Misocaのプロジェクト側での対応（環境変数を見てdefault_retry_countを設定）を行っていたのですが、一般的に使える便利な機能だと思われるため、本家のrspec_retryのリポジトリに、Pull Request (PR) を送ることにしました。
送ったPRはこちらです。機能本体のコードの他に、specとドキュメント（README.md）の修正も行いました。
送ったPRは、相手側でrebaseして別のPRとしてマージしてもらえました。
rspec-retry のバージョン 0.4.2以降から、今回送ったPRの機能を使うことができます。
まとめ
英語があまり得意ではないので、PRの説明文やドキュメントに書いた英語が通じるか心配でしたが、無事マージしてもらえて良かったです。
Misocaでは、他にもOSSのリポジトリに様々なPRを送っています。例えば最近では以下のPRがマージされました。
Misocaの開発には様々なオープンソースのライブラリを使わせてもらっているので、ライブラリ本体を改良した場合はできるだけフィードバックするように心がけています。また、変更点をライブラリのリポジトリにマージしてもらえれば、ライブラリがバージョンアップする時に、ライブラリ側の変更点と自分達が行った変更点がコンフリクトしなくなるメリットもあります。
