[Dressca-Admin]フロントエンドの自動テストサンプルを拡充する

[KentaHizume]

概要

DressacaのAdminについて、フロントエンドの自動テストサンプルを拡充する。

2025/1/24 時点

v 1.0 時点で下記のケースが実装されている。

• msw を使用し、ユースケースである正常系のCRUD操作を実行するコンポーネントレベルの結合テスト
• グローバルな状態（認証状態）に応じたUI（ボタン）の状態を確認する結合テスト

拡充したい内容

• 下記に対応して、ボタンを配列のINDEXで指定するのをやめたい。
  • 自動テスト時に同じHTML要素を区別するための実装方針を策定し反映する #1653
• 異常系のケースの実装
  • エラーを通知しているコンポーネント‘NotificationToast‘がApp.vueにいる関係で異常系をうまくAssertできない問題がある。
    • [Dressca-Consumer]フロントエンドの自動テストサンプルを拡充する #1482 (comment)
  • 他にUIに変化を持たせる／NotificationToastを各Viewに埋め込む／Vueからマウントする　の選択肢があるが、それぞれ好ましくない点がある状態。

完了条件

ここにこの Issue の完了条件を箇条書きで記載します。

[KentaHizume]

同じviewに対して、

• 複数ボタンを配置したケース
• 複数同じコンポーネントを配置したケース
  において、対象を取ってくる際に指定の方法が配列の順番指定になってしまうので、
  うまく解決する方法を検討すべき。

HTML要素についてはidを振るのが一つの方法だが、どのようなidを振るかを検討すべき。
カスタムデータ属性としてdata-testidを振る（プロダクションビルド時に削除する必要あり）
が、使わないといけない箇所は最小限にするような作りにすべき、というのが主流に見える。

https://qiita.com/akameco/items/519f7e4d5442b2a9d2da

describe('アイテム編集画面_アイテム削除機能のテスト', () => {
  it('アイテムを削除できる', async () => {
    const pinia = createPinia();
    setActivePinia(pinia);
    const customErrorHandler = createCustomErrorHandler();
    router.push({ name: 'catalog/items/edit', params: { itemId: 1 } });
    await router.isReady();
    const wrapper = mount(ItemsEditView, {
      global: { plugins: [pinia, router, customErrorHandler] },
    });
    await flushPromises();
    expect(wrapper.html()).toContain('カタログアイテム編集');
    await wrapper.findAll('button')[0].trigger('click'); // ここがイマイチ
    expect(wrapper.html()).toContain('カタログアイテムを削除します。');
    await wrapper
      .findAllComponents({ name: 'ConfirmationModal' })[0] // ここがイマイチ
      .findAll('button')[0] // ここがイマイチ
      .trigger('click');
    await flushPromises();
    expect(
      wrapper.findAllComponents({ name: 'ConfirmationModal' })[0].isVisible(),
    ).toBeFalsy();
    expect(wrapper.html()).toContain('カタログアイテムを削除しました。');
    await wrapper
      .findAllComponents({ name: 'NotificationModal' })[0]
      .findAll('button')[0]
      .trigger('click');
    expect(
      wrapper.findAllComponents({ name: 'NotificationModal' })[0].isVisible(),
    ).toBeFalsy();
  });
});

[KentaHizume]

サンプルを見る限り、Componentについても、data-testを指定できる。

https://test-utils.vuejs.org/api/#findAllComponents

[KentaHizume]

自動テストにおけるモックの使用方針

• mockモードでの画面の動作確認については、MSWを用いてAPIレスポンスをモックする
• 自動テスト（結合テスト）についてはVitestを用いてAPIレスポンスをモックする
  という方針が有力。

自動結合テストでMSWを用いることが過剰である理由は、
MSWを用いるメリットとして、
Vitestのメソッドレベルのモックと比較した場合に、
APIクライアント部分のモジュールを自動テストすることができることが挙げられるが、
Ales Maia/Maris においては、APIクライアント部分の実装にはopenapi-generator を使用しているため、
APIクライアント部分に対して自動テストをするメリットが薄いからである。
加えて、Vitestで完結させたほうが、テスト用のレスポンスのコードを凝集させやすい。

Vitestのモックを用いてエラーのレスポンスを表現する方法が要調査。