用語集 · UI 自動化
データ駆動テスト
英語: Data-driven testing
別名: データドリブンテスト, パラメータ化テスト, パラメタライズドテスト, data-driven tests
定義
同じテストロジックを多数の入力と期待結果の組み合わせで実行する手法で、データは各テストにコピーせず表・ファイル・データソースで管理します。
データ駆動テストは、テストが「何をするか」と「どのデータで行うか」を分離します。手順は一度だけ書き、そこにデータの行、つまり入力とそれぞれが生むべき結果を与えます。各行は独立したテストケースとして実行され、合否もそれぞれ判定されます。境界値分析や同値分割といった技法の成果を自動化する自然な方法です。
具体例(JUnit 5)
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;
import static org.junit.jupiter.api.Assertions.assertEquals;
class ShippingFeeTest {
@ParameterizedTest(name = "order of {0} costs {1} to ship")
@CsvSource({
"0.00, 4.99",
"49.99, 4.99",
"50.00, 0.00",
"250.00, 0.00"
})
void shippingFee(double orderTotal, double expectedFee) {
assertEquals(expectedFee, Shipping.feeFor(orderTotal), 0.001);
}
}
これには junit-jupiter-params アーティファクトが必要です。他のデータソースとして @ValueSource、@MethodSource、CSV ファイルに保存したデータ用の @CsvFileSource があります。
具体例(Playwright)
Playwright には専用のアノテーションはありません。ループでテストを生成し、それぞれに一意のタイトルを付けます。
import { test, expect } from '@playwright/test';
const cases = [
{ email: '', error: 'Email is required' },
{ email: 'not-an-email', error: 'Enter a valid email' },
];
for (const { email, error } of cases) {
test(`login rejects "${email}"`, async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill(email);
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByRole('alert')).toHaveText(error);
});
}
よくある間違い
- 異なる手順が必要な行。 半分の行で追加のクリックが必要なら、それは条件分岐を含む 1 つのテストではなく、2 つのテストです。
- 読めない名前。 各ケースの名前に主要な入力を含め、失敗レポートを見ればどの行が壊れたか分かるようにします。
- 巨大な外部スプレッドシート。 テストから離れた場所にあるデータはレビューしにくくなります。小さな表はインラインに置き、データが本当に大きい場合や他の人が管理している場合にだけファイルへ移します。
- 価値より量。 同じ同値クラスから 50 行追加しても、増えるのは実行時間だけでカバレッジは増えません。