test原因は、editアクションやupdateアクションでログインを要求するようになったため、ログインしていないユーザーだとこれらのテストが失敗するようになったためです。このため、editアクションやupdateアクションをテストする前にログインしておく必要があります。10.17に示します。10.17のsetupメソッド内でログイン処理をまとめてしまうことも可能です。10.2.3で片方のテストをログインする前に編集ページにアクセスするように変更したいので、ここでまとめてしまっても結局は元に戻すことになってしまいます。)今度はテストスイートがパスするはずです。testこれでテストスイートがパスするようになりましたが、実はbeforeフィルターの実装はまだ終わっておりません。なんと悪いことに、すべてのテストが成功してしまいました。beforeフィルターをコメントアウトして巨大なセキュリティーホールが作られたら、テストスイートでそれを検出できるべきです。redにならなければいけないのです。テストを書いて、この問題に対処しましょう。.endbeforeフィルターは基本的にアクションごとに適用していくので、Usersコントローラのテストもアクションごとに書いていきます。具体的には、正しい種類のHTTPリクエストを使ってeditアクションとupdateアクションをそれぞれ実行させてみて、flashにメッセージが代入されたかどうか、ログイン画面にリダイレクトされたかどうかを確認してみましょう。7.1から、適切なリクエストはそれぞれGETとPATCHであることがわかります。したがって、テスト内ではgetメソッドとpatchメソッドを使います。10.20に示します。10.20の2つ目のテストでは、patchメソッドを使ってuser_path(@user)にPATCHリクエストを送信している点に注目してください。7.1にあるように、このリクエストはUsersコントローラのupdateアクションへと適切に繋いでくれます。redになるはずです。するようになるはずです。testこれらのテストを実装したことによって、うっかり誰でも編集できてしまうバグがあっても、すぐに検知できるようになりました。演習デフォルトのbeforeフィルターは、すべてのアクションに対して制限を加えます。(結果としてテストも失敗するはずです)。正しいユーザーを要求する当然のことですが、ログインを要求するだけでは十分ではありません。ユーザーが自分の情報だけを編集できるようにする必要があります。10.2.1では、深刻なセキュリティ上の欠陥を見逃してしまうテストを見てきました。そこで本項では、セキュリティモデルが正しく実装されている確信を持つために、テスト駆動開発で進めていきます。補完するように、テストを追加するところから始めていきます。ユーザーの情報が互いに編集できないことを確認するために、サンプルユーザーをもう一人追加します。