ピン留めされたアイテム

[WIP] E2Eフレームワーク調査まとめ

Playwright

どの実行環境でもChroumium, Firefox, WebKitの3つをテストできる
Shadow DOMへのアクセスがしやすい
実機でのモバイルブラウザ対応は現在議論中
- Androidの自動化を実験的にサポートしている

TestCafe

唯一実機での自動テストをサポートしている
- remote機能で実現している

Cypress

E2E以外のテストも可能

CodeceptJS

様々なブラウザドライバーが利用できるラッパーライブラリ
I.amOnPage("https://example.com")やI.see("Title")といった自然言語に近い形式のテストコード

70_10

Playwright

公式サイト

https://playwright.dev

リポジトリ

https://github.com/microsoft/playwright

70_10

サポートブラウザ

Test on Chromium, Firefox and WebKit. Playwright has full API coverage for all modern browsers, including Google Chrome and Microsoft Edge (with Chromium), Apple Safari (with WebKit) and Mozilla Firefox.

Chromium, FireFox, WebKitに対応している。つまり、世の中のメジャーブラウザすべてをサポートしていると言える

FirefoxやWebKitは純粋なものではなく、Playwrightで独自にビルドしたものを利用しているよう。
「ユーザーが利用する正式なFirefox/Safariでテストしたい」というケースは、厳密には不可能ということになる

独自にビルドしたものを用意しているのでテストを実行しているマシンに依存しない。
どの環境であってもChromium, FireFox, WebKitのテストが可能。（WindowsでSafariのテストができるということになる）

参考資料

70_10

歴史

初リリースは2020年1月のv0.10.0と比較的新しい
Puppeteerから派生したライブラリとしてスタートしている
現在はPlaywright LibraryとPlaywright Testという棲み分けになっている
- Playwright Library
  - ヘッドレスブラウザのAPIライブラリ
- Playwright Test
  - Playwright Libraryを用いたE2Eテストフレームワーク

参考資料

70_10

Shadow DOMへのアクセス

Our css and text engines pierce the Shadow DOM by default

通常のCSSセレクタのようにShadow DOMへアクセスできるようになっている。
列挙している3つのフレームワーク（Playwright / TestCafe / Cypress)のなかで最も使いやすい。

70_10

テストコード

import { test, expect } from '@playwright/test';

test('basic test', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  const title = page.locator('.navbar__inner .navbar__title');
  await expect(title).toHaveText('Playwright');
});

@playwright/testに用意されたtestメソッドを使ってテストコードを書いていくスタイル。
test.describeも用意されており、MochaやJestで慣れ親しんだ書き方ができる。

async/awaitを使って書いていくあたりはやはりPuppeteerと似ている。

参考資料

70_10

テストの並列化

デフォルトではテストファイルは並行して実行され、単一ファイル内のテストは同一のワーカープロセスで順次実行される。

単一ファイル内のテストを並行実行するには、test.describe.parallel(title, callback)を利用する。

ワーカーのプロセス数のデフォルトは4。実行時もしくはconfigファイルでワーカー数を変更できる。

参考資料

70_10

実機モバイルブラウザの対応について

実機でのモバイルブラウザテストの対応については消極では内容で、議論が交わされている。
現在、Androidの自動化を実験的にサポートしている。

参考資料

70_10

ブラウザでの操作を記録する機能が用意されている

Selenium IDEのようなブラウザでの操作を記録し、コード化するコマンドラインが用意されている

npx playwright codegen wikipedia.org

参考資料

70_10

Auto Waiting

PlaywrightはPuppeteerととても似ている。
Puppeteerよりも優れている点として、Auto-Waitingがある。

Puppeteerでは、リンクをクリックしたあとに次のページが表示されるのを待つためにpage.waitingForSelector("css selector path")のようなコードを書く必要がある。

Playwrightはリンクをクリックすると自動的に次の画面の描画が完了するまで待機してくれる。
そのためPuppeteerよりも書かないといけないコードが少なくなる。

参考資料

70_10

TestCafe

公式サイト

https://testcafe.io

リポジトリ

https://github.com/DevExpress/testcafe

70_10

サポートブラウザ

Chrome, Edge, Firefox, Safariに加えてIEの名前まで上がっている。
特筆すべきはGoogle Chrom mobileとSafari mobileの名前も上げているところだろうか。

テストを実行するマシンのブラウザを使ってテストするので、そのマシンに対象のブラウザが存在しない場合はテストができない。
つまり、WindowsではSafariのテストはできないしMacではIEのテストはできない。

70_10

Remote機能を利用してモバイルブラウザをサポートしている

remoteというコマンドを用意しており、これを利用してモバイルブラウザをサポートしている。

testcafe remote foo.test.tsのようにテストを実行すると、URLが発行される。

このURLにテストしたい端末からアクセスすると、その端末のブラウザ上でテストが実行される。
iPhonのSafariでこのURLにアクセスすれば、iPhone Safariでテストが行われるということだ。

これ利用するにはテストを実行した（URLを発行した）ホストコンピュータへテストを行わせる端末がネットワーク接続できる必要がある。

参考資料

70_10

Shadow DOMへのアクセス

Selector.shadowRootメソッドを利用する。

Document APIに近い操作性で、少し手間がかかってしまう印象。

70_10

テストコード

import { Selector } from 'testcafe';

fixture `Getting Started`
    .page `http://devexpress.github.io/testcafe/example`;

test('My first test', async t => {
    await t
        .typeText('#developer-name', 'John Smith')
        .click('#submit-button')

        // Use the assertion to check if the actual header text is equal to the expected one
        .expect(Selector('#article-header').innerText).eql('Thank you, John Smith!');
});

fixtureメソッドでテストカテゴリを宣言し、その後にtestメソッドでテストコードを書いていく。
describe/itの書き方に慣れていると少し違和感がある。
階層によってテストコードのグルーピングを表すことができないのがやや扱いづらいか。

クリック・文字入力などのユーザー行動とアサーションはメソッドチェーンで書いていく。
一昔前の雰囲気（gulpが主流だった時代）を思い出させる。

参考資料

70_10

Cypress

公式サイト

https://www.cypress.io/

リポジトリ

https://github.com/cypress-io/cypress

70_10

サポートブラウザ

Chrome, Edge, Firefoxなどの有名どころはサポートしている

Cypress automatically detects available browsers on your OS.

「OSで利用できるブラウザを自動的に検出する」とあるが、これはつまりOSにそのブラウザがインストールされていないといけない（＝OSのブラウザを使ってテストする）ということだろうか

モバイルブラウザ（iPhone SafariやAndroid Chromeなど）には対応できないということになる。
また、Safari（WebKit）はサポートしておらず、今現在積極的にサポートしようという状態にない。

参考資料

70_10

Shadow DOMへのアクセス

.shadow()を利用してアクセスする。

Document APIに近い操作性。TestCafeと同じように少し手間がかかる印象。

70_10

テストコード

describe('My First Test', () => {
  it('Gets, types and asserts', () => {
    cy.visit('https://example.cypress.io')

    cy.contains('type').click()

    // Should be on a new URL which includes '/commands/actions'
    cy.url().should('include', '/commands/actions')

    // Get an input, type into it and verify that the value has been updated
    cy.get('.action-email')
      .type('fake@email.com')
      .should('have.value', 'fake@email.com')
  })
})

describe/it形式で書く。
cyにすべてが用意されている。

参考資料

70_10

ディレクトリ構成が決められている

最初にcypress openを実行すると、プロジェクトに以下のような構成のcypressディレクトリが作成される。

cypress
├── fixtures
├── integration
├── plugins
├── support
└── videos

この構成に沿ってテストケースを作成していく。

70_10

E2E以外のテストもできる

ReactのコンポーネントテストやAPI呼び出しのテストもできる

参考資料

70_10

CodeceptJS

公式サイト

https://codecept.io/

リポジトリ

70_10

特徴

BDDスタイルのE2Eテストフレームワーク

I.amOnPage("https://example.com")のようにIオブジェクトを使って自然言語に近い記述のテストコード。

Feature('CodeceptJS demo');

Scenario('check Welcome page on site', ({ I }) => {
  I.amOnPage('/');
  I.see('Welcome');
});

様々なブラウザドライバー（ヘルパー）が利用できる

CodeceptJSはブラウザドライバー（CodeceptJSではヘルパーと呼んでいるので、以下ヘルパーと呼ぶ）のラッパーライブラリとも言える。
選べるヘルパーは6つ

Playwright
WebDriver
Puppeteer
Protractor
Nightmare
TestCafe

クロスブラウザ・パフォーマンスの高さから、CodeceptJSではPlaywrightを推奨している。

要件によってヘルパーを変更できるので、同じコードでも裏側はPlaywrightで動いたりTestCafeで動いていたりということができる。
ヘルパーによってできる・できないがあるので、ヘルパーを変更してもすべてのテストコードが動くという保証はしていない。

70_10

Shadow DOMへのアクセス

使用するヘルパーに依存する。
Playwrightを使用していれば、ShadowDOMであることを意識せずにアクセスできる。

それ以外のヘルパーでは一工夫が必要になっている。
CodeceptJS自体もShadow DOMへのアクセスをシンプルにする方法を提供しているが、現在すべてのヘルパーには対応していない。利用できるのはWebDriverのみ。

すべてのヘルパーでShadow DOMのサポートをするIssueが立てられてはいるが議論は進んでいない。

参考資料

https://codecept.io/shadow/