用語集 · UI 自動化
テストフィクスチャ(Test Fixture)
英語: Test fixture
別名: test fixtures, フィクスチャ, fixtures, フィクスチャー
定義
ブラウザーのページ、投入済みのユーザー、データベースなど、テストの実行前に必要な固定の準備と、実行後にそれを片付ける後処理のことです。
テストフィクスチャとは、テスト対象の振る舞いそのもの以外で、テストが依存しているすべてのものです。つまり、最初の手順を実行する前に既知の状態になっている必要があるオブジェクト、データ、接続、環境です。良いフィクスチャは毎回同じ方法でその状態をセットアップし、終了後に片付けるため、各テストはクリーンな状態から始まります。この言葉は、Cypress が cy.fixture() で読み込む JSON ファイルのような、静的なテストデータファイルを指して、より緩い意味で使われることもあります。
例(Playwright)
Playwright ではフィクスチャが第一級の機能です。page や request のような組み込みのフィクスチャは名前で注入され、独自のフィクスチャは test.extend で追加します。
import { test as base, expect } from '@playwright/test';
import { TodoPage } from './todo-page';
type Fixtures = { todoPage: TodoPage };
export const test = base.extend<Fixtures>({
todoPage: async ({ page }, use) => {
const todoPage = new TodoPage(page); // setup
await todoPage.goto();
await use(todoPage); // the test runs here
await todoPage.removeAll(); // teardown
},
});
test('adds an item', async ({ todoPage }) => {
await todoPage.add('Write the glossary');
await expect(todoPage.items).toHaveCount(1);
});
フィクスチャはテストが要求したときにだけ作成され、ほかのフィクスチャに依存することもできます。スコープはテスト単位(デフォルト)にも、コストの高いリソース向けに { scope: 'worker' } でワーカー単位にもできます。
例(JUnit 5)
xUnit 系のフレームワークでは、フィクスチャはライフサイクルメソッドに置きます。
class CartServiceTest {
private CartService cart;
@BeforeEach
void setUp() {
cart = new CartService(new InMemoryCartRepository());
}
@AfterEach
void tearDown() {
cart.clear();
}
@Test
void emptyCartHasZeroTotal() {
assertEquals(0, cart.total());
}
}
@BeforeAll と @AfterAll はクラスごとに 1 回実行され、デフォルトでは static にする必要があります。
よくある間違い
- 変更可能なフィクスチャの状態をテスト間で共有する。 ワーカー単位のユーザーをテストが変更すると、実行順序に依存した失敗が起きます。
- テストが失敗したときに後処理を飛ばす。 クリーンアップはテスト本体の最後ではなく、フィクスチャ内(
useの後)や@AfterEachに置きましょう。 - すべてを 1 つの巨大なフィクスチャにまとめる。 小さく組み合わせ可能なフィクスチャにすると、各テストが何に依存しているかが明確になります。