E2Eのテストフレームワークとして最近CodeceptJSというライブラリを知りました。 GitLabでの導入が簡単だったので早速導入しているのですが、これまでE2Eテストのノウハウがないため常に探りながらの状態で進めています。 幸いBest Practiceというページが存在しているので、後学のためにDeepLで翻訳した文章をまとめてみました。

読みやすさを重視する

CodeceptJSでは、ユーザーがテストを書く際にページ上のセマンティックな要素に従うことを推奨しています。CSS/XPathロケータの代わりに、ページ上で目に見えるキーワードにこだわるようにしてください。

次の例を見てみましょう:

// これも良いのですが...
I.click({ css: 'nav.user .user-login' });
// この方が良いかもしれません
I.click('Login', 'nav.user');

生のCSSセレクタをボタンのタイトルに置き換えると、このようなテストの可読性を向上させることができます。ボタンのテキストが変更されても、それを更新するのがはるかに簡単になります。

もしあなたのコードがIオブジェクトやページオブジェクトの使用を超えている場合、あなたは何か間違ったことをしている可能性があります。

テキストと要素を一致させるのが難しい場合は、ロケータビルダーを使うことをお勧めします。これを使えば、FluentなAPIを介して複雑なロケータを構築することができます。つまり、ボタンやリンクではない要素をクリックしてそのテキストを使いたい場合は、locate()を使って読めるロケータを作ることができます。

// 次の要素をクリックします <span class="button">Click me</span>
I.click(locate('.button').withText('Click me'));

ショートカットを使用する

よりシンプルで効果的なテストを書くためには、ショートカットを使うことをお勧めします。テストを一つの機能に集中させ、テストに直接関係のないものはすべて単純化するようにしてください。

  • テストにデータが必要な場合は、API経由でデータを作成するようにしてください。その方法はデータ管理の章を参照してください。
  • ユーザーのログインが必要な場合は、ログインのステップをテストの中に入れる代わりにautoLoginプラグインを使用してください。
  • 長いテストはいくつかに分割しましょう。長いテストは壊れやすく、フォローや更新が複雑になります。
  • カスタムステップやページオブジェクトを使用して、現在のテストに関係のないステップを非表示にします。

次のようにテストをシンプルにできます:

Scenario('editing a metric', async (I, loginAs, metricPage) => {
  // autoLoginでログイン
  loginAs('admin');
  // ApiDataFactoryでデータを作成する
  const metric = await I.have('metric', { type: 'memory', duration: 'day' });
  // ページオブジェクトを使ってページを開く
  metricPage.open(metric.id);
  I.click('Edit');
  I.see('Editing Metric');
  // カスタムステップを使用する
  I.selectFromDropdown('duration', 'week');
  I.click('Save');
  I.see('Duration: Week', '.summary');
});

リファクタリングとPageObject

プロジェクトが大きくなり、より多くのテストが必要になってきたら、テスト全体でテストコードを再利用することを考えるべきです。いくつかの一般的なアクションは、異なるテストからアクセスできるように、テストから他のファイルに移動する必要があります。

ここでは、何をどこに保存するかの推奨される戦略を紹介します:

  • ドロップダウン、リッチテキストエディタ、カレンダーのようなサイト全体の共通コントロールを使用して、ログインのようなサイト全体のアクションはActorファイル(custom_steps.jsファイル)に移動します。
  • ページベースのアクションやセレクタをページオブジェクトに移動します。そのページで行われたすべてのアクションは、ページオブジェクトのメソッドに移動することができます。SPAをテストする場合、ページオブジェクトはアプリケーションの画面を表すべきです。
  • サイト全体のウィジェットが使用されている場合、それらとのインタラクションはPage Fragmentsに置かれるべきです。これは、グローバルナビゲーション、モーダル、ウィジェットに適用されるべきです。
  • 低レベルのドライバアクセスを必要とするカスタムアクションは、ヘルパーに置くべきです。例えば、データベース接続、複雑なマウスアクション、メールテスト、ファイルシステム、サービスアクセスなどです。

さまざまなリファクタリングオプションについての詳細はこちらをご覧ください。

しかし、オーバーエンジニアリングはせず、テストはシンプルにしておくことをお勧めします。この時点でテストコードが再利用を必要としない場合は、ページオブジェクトを使用するように変換すべきではありません。