0

これは技術的な質問であると同時に、プログラミングの練習問題でもあると思います。

私は Ruby on Rails チュートリアルを行っており、第 7 章の演習の質問 2 まで完了しています。この質問では、無効なユーザーのエラー メッセージが再読み込みされたサインアップ ページに表示されることを確認するテストを作成するよう求められます (パスワードが空白、電子メール アドレスが無効など)。 ）。

十分に機能するコードがいくつかありますが、実際に何かをテストしているとは感じません。サインアップ ページに空白のユーザーを手動で入力したときに表示されるエラー メッセージの存在を簡単にテストしました。当然のことながら、テストは成功しました。エラー メッセージをコピーしてテストに貼り付けただけです。

私の関連部分は次のuser_pages_spec.rbとおりです。

describe "signup" do

before { visit signup_path }

let(:submit) { "Create my account" }

describe "with invalid information" do
  it "should not create a user" do
    expect { click_button submit }.not_to change(User, :count)
  end
  describe "after submission" do
    before { click_button submit }
    it { should have_selector('title',text: 'Sign up') }
    it { should have_content('error') } 
    it { should have_content('Password digest can\'t be blank') }
    it { should have_content('Name can\'t be blank') }
    it { should have_content('Email can\'t be blank') }
    it { should have_content('Email is invalid') }
    it { should have_content('Password can\'t be blank') }
    it { should have_content('Password is too short (minimum is 6 characters)') }
    it { should have_content('Password confirmation can\'t be blank') }
  end
end

これは正しい方法ですか？エラーメッセージ/翻訳が何であるかをRubyに教えてもらい、それらをテストするべきではありませんか? パスワードの長さなど、検証条件の 1 つを変更するとどうなりますか? 同様に、Password Digest に関するエラー メッセージを修正する場合、テスト ファイルを変更する必要がありますか?

編集:正確なエラー文字列がわからない場合はどうすればよいですか? Ruby は、エラー メッセージが何であるかをテストに伝える必要がありますか? これには「have(x).errors_on」を使用する必要がありますか? .

4

1 に答える 1

1

ユーザーがパスワードではなくユーザー名を挿入したり、結果を確認したりするかどうかをテストする場所にいつでもテストを拡張できます。しかし、それはやり過ぎだと思います。それ以外は大丈夫だと思います。

エラーメッセージを変更する場合は、テストを変更する必要があります。しかし、TDDがどのように機能するかを考えてみましょう。テストを記述し、次にコードを記述し、必要に応じてリファクタリングします。したがって、理想的には、検証条件が何であるかをすでに知っているはずです。後でコードを変更したい場合は、テストを変更してから、コードを変更します。

テストに関するRubyonRailsガイドから：

Ideally, you would like to include a test for everything which could possibly break. It’s 
a good practice to have at least one test for each of your validations and at least one 
test for every method in your model.

これをモデルだけでなく、コントローラー、ルーティングなどにも拡張できます。つまり、コードの動作をテストします。たとえば、ユーザーがサインインしたときにフラッシュメッセージが表示される場所に設定した場合は、テストして、ユーザーにそのフラッシュメッセージが表示されることを確認します。ユーザーが何か間違ったことをして別のフラッシュメッセージが表示されるはずの場合は、テストして別のフラッシュメッセージが表示されることを確認します。

Hartlのチュートリアルを終えたら、shouldaマッチャーをチェックすることを検討します。

これは、rspecのベストプラクティスに関する簡単なreadmeです。

最後に、Wolfram Arnoldの6部構成のチュートリアルシリーズは、少し時代遅れですが、何をテストするかを学ぶのに役立ちます。

編集：もちろんカスタムメッセージを書かない限り、Railsが事前に書いたエラーメッセージをテストに書く必要があります。ありがたいことに、 Ruby国際化または略してRubyl18n内で事前に作成されたエラーを見つけることができます。予想されるメッセージのリストは次のとおりです。

  inclusion: "is not included in the list"
  exclusion: "is reserved"
  invalid: "is invalid"
  confirmation: "doesn't match confirmation"
  accepted: "must be accepted"
  empty: "can't be empty"
  blank: "can't be blank"
  too_long: "is too long (maximum is %{count} characters)"
  too_short: "is too short (minimum is %{count} characters)"
  wrong_length: "is the wrong length (should be %{count} characters)"
  not_a_number: "is not a number"
  not_an_integer: "must be an integer"
  greater_than: "must be greater than %{count}"
  greater_than_or_equal_to: "must be greater than or equal to %{count}"
  equal_to: "must be equal to %{count}"
  less_than: "must be less than %{count}"
  less_than_or_equal_to: "must be less than or equal to %{count}"
  odd: "must be odd"
  even: "must be even"

上記のエラーメッセージの先頭に検証している属性をテストと出来上がりに挿入します。これは、Railsから期待されるエラーメッセージです。

そして最後にhave(x).errors_on、フラッシュメッセージをテストする方法の1つです。ショルダーマッチャーには、フラッシュメッセージテスト専用の関連ページもあります。余分なものはやり過ぎだと思います。

于 2012-12-13T08:08:53.863 に答える