自動化テストの設計は、今日のソフトウェア開発において基本的な部分ですが、そのメンテナンスはしばしば悪夢のようになります。UIが変更されるたびに、ボタンの名前変更、CSSクラスの変更、HTML構造の変更など、テストロケーターが機能しなくなり、テストを更新する必要があります。これにより、常にやり直し作業が発生し、高いメンテナンス負担が生じます。このブログでは、data-testid属性と中央集約されたテストIDを使用してPlaywrightテストを実施するメンテナンス不要のアプローチを探ります。この方法は、過労を制限し、ソフトウェアの全体的な信頼性と堅牢性を向上させるのに役立ちます。
問題点：なぜテストのメンテナンスが難しいのか
自動化テストは、アプリケーションが静的でないため、維持が難しいです。以下は一般的な問題点です：
- 脆弱なロケーター： テストはしばしばCSSセレクターやXPathのようなロケーターに依存して要素を識別します。しかし、UIに変更があると、例えばボタンのクラス名やレイアウトの更新など、これらのロケーターが無効になり、テストが失敗することがあります。
- 労力の重複： ロケーターが変更されると、開発者とQAエンジニアの両方がテストやページオブジェクトを見直して必要な更新を行う必要があります。このプロセスは労働集約的であり、ミスが発生しやすいです。
- 一貫性の欠如： ロケーターを定義するための統一されたアプローチがない場合、さまざまなチームメンバーが異なる方法を採用する可能性があり、矛盾や混乱を引き起こします。
- テストとUIの密結合： UIの構造に大きく依存するテストは、特定の実装詳細に密接に結びついています。この依存関係がテストを脆弱にし、維持が難しくなります。
解決策：ロケーターメソッドを使わず、中央集約された場所からdata-testidを使用する
これらの問題を解決するために、data-testid属性を利用したメンテナンス不要のソリューションを取ることができます。以下がその方法です：
中央集約されたテストID： すべてのテストIDを一つの中央集約された場所（例：utils/testIds）に宣言します。これらのIDはアプリケーションコードとテストコードの両方で使用されます。
テストをUI構造から分離： CSSセレクターやXPathを使用せず、data-testid (page.getByTestId) を使用する 属性を使用して要素を一意に識別します。これにより、テストがUI構造から分離され、変更に対してより安定します。
再利用可能なテストID： アプリケーションとテスト全体で同じテストIDを共有することで、一貫性を確保し、重複を減らします。
このアプローチを実装する方法
ステップ1：中央集約された場所にテストIDを定義する
すべてのテストIDを保存するファイル（例：utils/testIds.ts）を作成します。例えば：
// utils/testIds.ts
export const USERS_TEST_IDS = {
userTable: {
userMenuButton: 'user-menu-button',
removeButton: 'remove-button',
},
};
ステップ2：アプリケーションコードでテストIDを使用する
アプリケーションコードで、これらのテストIDをdata-testidとして使用する 属性として使用します。例えば：
import { USERS_TEST_IDS } from "@/utils/testIds";
<IconButton
onClick={handleMenuClick}
data-testid={USERS_TEST_IDS.userTable.userMenuButton}
>
<MoreHorizontalIcon />
</IconButton>
ステップ3：PlaywrightテストでテストIDを使用する
Playwrightテストやページオブジェクトで、同じテストIDをインポートして要素を特定するために使用します。例えば：
import { USERS_TEST_IDS } from "@/utils/testIds";
class UsersPage {
constructor(private page: Page) {
this.adminMenuButton = page.getByTestId(
USERS_TEST_IDS.userTable.userMenuButton
);
this.menuRemoveButton = page.getByTestId(
USERS_TEST_IDS.userTable.removeButton
);
}
async removeSpecificAdmin(userName: string) {
await this.searchUser(userName);
await expect(this.page.getByText(userName)).toBeVisible();
await expect(this.adminMenuButton).toBeVisible();
await this.adminMenuButton.click();
await expect(this.menuRemoveButton).toBeVisible();
await this.menuRemoveButton.click();
await this.commonPageUtil.clickOnButton("Yes, Remove");
}
}
このアプローチの利点
- メンテナンス不要： data-testid属性はUI構造ではなく機能に結びついているため、UIの変更（例：クラス名、階層）によってテストが妨害されることはありません。
- 一貫性： テストIDを中央集約することで、アプリケーションとテスト全体で同じIDが使用され、重複や不一致が最小限に抑えられます。
- 読みやすさの向上： テストはより読みやすく、自己説明的になります。各要素の目的がテストIDから理解されます。
- デバッグの迅速化： テストが失敗したときに失敗の原因を特定しやすくなります。テストIDが失敗した要素への直接的な指針を提供します。
- 協力の強化： 開発者とQAエンジニアは、各自のコードベースで同じテストIDを共有するため、より良い協力が可能になります。
- 将来への備え： この手法は、将来の変更に対してテストをより強靭にし、テストスイートの長期的な維持コストを下げます。
ベストプラクティス
- 説明的なテストIDを使用する： テストIDを説明的で要素の目的を表すものにします。例えば、button-1ではなくuser-menu-button。
- テストIDの過剰使用を避ける： 実際にテストで参照される要素にのみdata-testid属性を含めます。不要な属性でコードを覆わないでください。
- テストIDを中央集約する： すべてのテストIDの真実の一元化された情報源を持ち、重複や不一致を防ぎます。
- テストIDを文書化する： 特に多くの場所で使用される場合、各テストIDが使用される理由をコメントまたは文書化します。
結論
data-testid属性を通じてPlaywrightテストのメンテナンス不要モデルを採用することで、テストスイートの維持に必要な労力を大幅に削減できます。これにより、テストがより強力で信頼性が高くなるだけでなく、開発者とQAエンジニアの間の協力が簡素化されます。中央集約されたテストIDと関心の分離を持つことで、壊れたテストを修正するのではなく、機能の提供に集中できるようになります。
