表題の通り、Qiitaに投稿した。
RSpecでエラーが起きたあとの状態をテストするときの問題点と回避案 - Qiita
一応記事内では蛇足になりそうだったのでなんでこんなものを書いたのかの編集後記的補足。
今回実環境でやりたかったこと
サービスクラスを実装していたので、複数のテーブルのデータを1メソッドでザクッと変更する処理を書いていた。そのため、メソッドの処理が失敗してraiseしたらちゃんと他の処理もロールバックしているのかを調べたかった。
その末色々調べてみたこと
raiseすることを確認するのは以下のコードでできるのは探せば結構出てきた
# raise_error({{対象のStandardError}}) で確認可能。 expect { object.error_okiru_yatsu }.to raise_error(ZeroDivisionError)
ただこの場合には『エラーが起きる行動を実行すると、意図したエラーがあがる』というテストである
ただ個人的には
- 例外が起きる何かを設定する
- テストしたい行動を実行すると設定値のせいで処理が成功しない
- 処理が成功しなかった場合に関連する値が意図しないものになっていない
とあった場合に3番目を確認したかったので、上の方法を混ぜるのは何か違う気がしていた。 そのため、記事内の処理をやるに至ったのだが、なんかコレジャナイ感をはらむ結論が出た。
なので今回はQiitaに書いてみた
今回割と微妙な内容ではあったが
- 日本語でコレに関しての情報がない
- 割と他の方法論があるのであれば知りたい
- ただはてブだと埋もれそう
などの理由からQiitaに書いてみて、突っ込まれたらそれを吸収する方法論をとりました。
まぁあんまり見られないかなと思いつつ、なんかフィードバックがあったら嬉しいなぐらいの気持ちです。
