• 記事更新の API とテストの実装を行いましょう。

1. どこをテストするか

• 対象：PATCH /api/v1/articles/:id（記事更新）
• 範囲： Api::V1::ArticlesController の update（記事更新API）
• 前提：認証は未実装のため、current_user はスタブで固定してテストする

2. 何を期待するか

• status：200
• JSONの形（配列 / オブジェクト）：オブジェクト

3. 前提準備

• letで用意しているもの
  • current_user として扱うテストユーザー（test_user）
  • 更新対象の記事（article：投稿者は test_user）
  • （権限エラー用）別ユーザー（other_user）
• letを使う理由
  • テストで使うデータ（user/articleなど）を「名前付き」で用意できるため
    • test_user や article のように、テスト内で意図が読み取りやすくなる
  • 必要になったタイミング（メソッドを呼んだ時）でだけ作られるため（遅延評価）
    • 使わないデータは作られず、テストが無駄に重くなりにくい
  • スコープで使える範囲をコントロールできるため
    • describeで定義すれば配下のit/contextで使える
    • context内で定義すれば、その条件のテストだけに限定できる（正常系と権限エラーでユーザーを分けやすい）

4. リクエスト送信

• HTTPメソッド：PATCH
• パス：/api/v1/articles/:id（例：/api/v1/articles/#{article.id}）
• params：articleキー配下に更新したい値を入れて送る
  • article: { title: “…”, body: “…” }

5. expect（何を確認しているか）

• expect（status）
  • :ok（200）が返ること（正常系）
    • 理由：記事更新リクエストが成功したことを確認するため
  • :forbidden（403）が返ること（権限エラー）
    • 理由：投稿者本人以外は更新できないことを確認するため
  • :not_found（404）が返ること（記事が存在しない）
    • 理由：存在しない記事IDを指定したときに正しくエラーを返せることを確認するため
• expect（レスポンスの中身）
  • title と body が更新後の値になっていること（正常系）
    • 理由：DB更新の結果がレスポンスにも反映されていることを確認するため
  • user.id が test_user.id と一致すること（正常系）
    • 理由：更新対象の記事の投稿者が想定通り（test_user）であることを確認するため
  • error メッセージが返ること（権限エラー / 404）
    • 理由：失敗理由をクライアント側で表示・判断できるようにするため