Adminについてバックエンド・フロントエンド間の結合テストを行う

[KentaHizume]

概要

Adminアプリについて、
別々に開発していたバックエンド-フロントエンド間の結合テストを行う。
PRの差分とレビュー観点をわかりやすくするために、
developブランチに統合してから、mainブランチにマージする。

タスク

• バックエンド分をdevelopにマージ
• フロントエンド分をdevelopにマージ
• developでバックエンド-フロントエンド間の結合テスト
• 結合テスト結果のレビュー

完了条件

• Adminのフロントエンド・バックエンド間の連携が想定通り動作すること

[KentaHizume]

api-docs配下のフォルダ階層が深くなっているので、
consumer側もpackage.jsonで指定しているパスの修正が必要。

$ ls ./../../dressca-backend/api-docs/
web-admin/  web-consumer/

[KentaHizume]

API定義の差分

一旦全量比較する

PostCatalogItemRequest/PutCatalogItemRequestに差分

maia側はPostにrowVersionがあり、PutにrowVersionがない（更新処理につくべきなので逆）

CatalogItemResponseに差分

maia側はCatalogItemResponesにrowVersionが含まれていないので、
クライアント側から楽観ロック用のキーをリクエストに含められず、
楽観ロックが実装できない。そのためrowVersionをResponseに含める必要がある。

getById の戻り値の型

maia：PagedListOfCatalogItemResponse
maris：CatalogItemResponse
で、返している型が異なる。
getByIdで2個以上のアイテムが返ることはないので、
ページネーションしないCatalogItemResponseでいいはず。

PagedListOfCatalogItemResponse

既知の事象だが、妥当なほうに合わせておきたい。

• Maia-Maris間でPagedListOfCatalogItemResponseの構造が異なる #1215
  marisがtotalPages、hasPrevious、hasNextの3つ多く持っている。
  現状機能としては使っていない。
  この3つはクライアント側でも他の値から導出可能なので返していないものと思われる。

    this.TotalPages = (int)Math.Ceiling(totalCount / (double)pageSize);

    /// <summary>
    ///  前のページが存在するかどうか示す値を取得します。
    /// </summary>
    public bool HasPrevious => this.Page > 1;

    /// <summary>
    ///  次のページが存在するかどうか示す値を取得します。
    /// </summary>
    public bool HasNext => this.Page < this.TotalPages;

[KentaHizume]

PagedListOfCatalogItemResponseについてはMaris側に合わせる。
totalPages、hasPrevious、hasNextについては一般的に検索系のAPIでよく返す値のため。

[KentaHizume]

• 正しいポート番号の設定が必要

# 開発環境において Web API をプロキシ経由で呼び出す際のエンドポイントです。
VITE_PROXY_ENDPOINT_ORIGIN=http://localhost:8081

• CORSの設定に関して、ガイドに記載の下記の行がないので要否の確認が必要。

conf.addExposedHeader("Location");

[KentaHizume]

Consumerも同様の仕様だが、500エラーのときはエラー画面（/error）に遷移したほうがよい？

[KentaHizume]

認証を透過している関係でPermissionDeniedExceptionを打鍵で出すのが難しい。
デバッグ実行では出せるが、そうであればバックは単体テストで確認、フロントはmockで確認で代替でよさそう。

あとは未認証ユーザーでのAPIコールも確かめられない。

[KentaHizume]

No	機能	正常系・異常系	レスポンスコード	操作	期待値
1	ユーザー情報取得	正常系	200 OK	・ホーム画面でログインする	・ヘッダーにユーザー名とロールが表示されること
2	アイテム一覧表示	正常系	200 OK	・アイテム一覧画面に遷移	・アイテムの一覧が表示されること
3	アイテム取得	正常系	200 OK	・アイテム編集画面に遷移	・対象のIDのアイテムの情報が表示されること
4	アイテム取得	異常系	404 Not Found	・存在しないIDをURIに指定してアイテム編集画面に遷移 （catalog/items/edit/999）	・エラーメッセージが表示されること
5	アイテム追加	正常系	201 Created	・アイテム追加画面に遷移 ・「追加」ボタンを押下	・追加したアイテムの内容が表示されること
6	アイテム更新	正常系	204 No Content	・アイテム編集画面に遷移 ・アイテム名、説明、単価、商品コード、カテゴリ、ブランドを変更 ・アイテム追加画面で、「更新」ボタンを押下 ・アイテム一覧画面に遷移	・更新後のアイテムの内容が表示されること
7	アイテム更新	異常系	404 Not Found	・タブAでアイテム編集画面に遷移 ・タブBでアイテム編集画面に遷移 ・タブAでアイテムを削除 ・タブBでアイテムを更新	・エラーメッセージが表示されること ・削除したアイテムが存在しないこと
8	アイテム更新	異常系	409 Conflict	・タブAでアイテム編集画面に遷移 ・タブBでアイテム編集画面に遷移 ・タブAでアイテムを更新 ・タブBでアイテムを更新	・エラーメッセージが表示されること ・アイテムの情報がタブAで更新した内容であり、タブBの更新は反映されていないこと
9	アイテム削除	正常系	204 No Content	・アイテム編集画面に遷移 ・「削除」ボタンを押下	・アイテム一覧画面で削除したIDのアイテムが表示されないこと
10	アイテム削除	異常系	404 Not Found	・タブAでアイテム編集画面に遷移 ・タブBでアイテム編集画面に遷移 ・タブAでアイテムを削除 ・タブBでアイテムを削除	・エラーメッセージが表示されること

[KentaHizume]

念のためnpm run generate-clientをして想定外の差分が発生していないかを確認しておく。

[KentaHizume]

更新と削除が競合した場合に、アイテム削除の HTTP DELETE のコールで 409 が検出されて適切にハンドリングされることを確認する必要がある。