見出し画像

Rspec

1 : r.specに「--require rails_helper」を記述しない理由

1 : 仮説検証

Ruby機能をテストするための設定である
「--require spec_helper」はr.specファイルにデフォルトで記述あり。

「--format documentation」を追記するなら、
「--require rails_helper」も記述すればいいのでは、と考えた。

だが、Railsを使った機能のテストファイルを
rails g specコマンドでファイルを生成すると
「require 'rails_helper'」がデフォルトで記述される。

つまり、r.specファイルにも記述すると2度読み込むことになってしまう。
それは、スマートではない。

またr.sepcファイルは全テストに対する設定ならば、
Railsを使わないRubyだけのテストを行うには不要な記述となる。
こちらの意味でもスマートではない。

1 : 質問で深まった内容

1度読み込んでいたら、2度目の読み込み指示がスルーされるわけではなく、
2度読み込まれることになる。
エラーが生じることはないが、仮説の通りr.specに書く必要性がない。

2 : Rspecの導入にあたり、
group :development, :test do ~ end内に記述する理由

2 :  仮説検証

開発、テスト環境のグループと見受けられる。
また、データベース設定において、開発・テスト・本番環境ごとに
異なる設定ができたことから、Gemfileも同じ設定が可能とみる。

リリースしたアプリに、デバックツールであるRspecは不要のため、
導入環境を制限したと予測する。

2 : 質問で深まった内容

なぜテスト環境単体でなく、開発&テスト環境なのか疑問だった。

テスト自体が開発の一部であり、開発の中でテストを行なっているイメージ
という説明で、なるほど!と、納得。

3 : bundle execを使うかどうかの判断

3 :  仮説検証

bundle execで実行すると、Gemfile.lockに記載された「依存関係に基づくバージョン」のGemを実行する。
そこから、使わないと最新verで実行になると予測。

devise使用時にbundle execコマンドが不要だったのは、
devise導入時は、依存するGemが、他のGemで使用されていなかったからではないか。(競合がなかった)

3 : 質問で深まった内容

競合がなかっというより、
deviseというGemは、「Gemの依存関係を解消しているGem」なので
bundle execコマンドなしでも動く。

対し、Rspecは、Gemの依存関係の解消はされていないGemなので
bundle execでの実行が推奨されている。

競合Gemの有無というより、
使いたいGemは、依存関係の解消がなされているか否か、
という点がポイントになるのか、と間違いに気づけた。



4: bundle exec rspecで指定するファイル名は
spec/xxx~でなく、xxx~ではだめなのか。

4 :  仮説検証

rspecコマンドを実行すると、デフォルトでspec以下のファイルが読み込まれる。
では、その下層ディレクトリからファイルを指定しても良いではないかと考えた。

実行した結果、エラーとなった。
そういう仕様で作られているものだと、解釈した。

4 : 質問で深まった内容

そのような仕様だが、
概ね、一番上層のディレクトリから指定することが多い。
(app/~ や、config/~など)


5 :valid?で生じたエラーは、本当にインスタンスに保存されているのか。

5 :仮説検証

valid?実行で、falseとなった場合、エラーが生成される。
コンソールで、インスタンスを生成し、valid?でfalseの出力を確認。
その後インスタンスのみを出力したが、エラーメッセージは表示されなかった。

だが、インスタンスに対しerrorsメソッドを実行すると、エラーが出力された。

結論、インスタンスにエラーメッセージは保存されているが、
errorsメソッドを使わないと、確認できないと予想。

5 :質問で深まった内容

目に見える形で確認するなら、errorsが必要。