Kaigi on Rails 2022の登壇資料です! https://kaigionrails.org/2022/talks/ikumatdkr/
Playwright が昨年1年間で大幅パワーアップしていたので、使い方を確認したときの記録のまとめです。 ブラウザを自動操作できるということは、簡単なスクレイピングやブラウザ側のテスト自動化が簡単にできるようになります。 特に、Python での解説がまだまだ少なかったので、自分の学習を含めてまとめました。 今回は入門編ということで全体像をつかみつつ使用方法の流れを確認していただければありがたいです。 Selenium や Puppeteer を使っている方も、一度試す価値ありと思っています。 選定した理由 ブラウザのテストを Python で自動化したかったんです。 私なりの要件がありまして、非常にわがままな要件でしたが余裕ですべてクリアしました。 Python で書けること。社内で Python を使える方が多いので。pytest と連携してくれるとなおうれしい。 Docker コン
ウェブブラウザを自動操作する際には、WebDriverやChrome DevTools Protocol (CDP) などのAPIが広く利用されています。 これらのAPIを基盤に構築された様々なブラウザ自動操作フレームワークが、テスト自動化の分野で重要な役割を果たしています。 例えば、SeleniumやPlaywrightといったフレームワークを利用して、テストの自動化に取り組まれている方もいらっしゃると思います。 私もテスト自動化フレームワークの便利さを享受する一方で、フレームワークを介さずにブラウザを自動操作する方法についての興味がわいてきました。 そこで、この記事ではWebDriverやCDPが提供するAPIを直接利用してブラウザを操作する方法を基礎から探求してみることにしました。 これにより、私たちが普段利用しているフレームワークの背後にある原理を理解し、より深い知見を得ることを目
マイクロソフトは、Webアプリケーションのテスト自動化ライブラリ「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプレビュー公開を発表しました。 Microsoft Playwright Testingに使われている「Playwright」は、マイクロソフトが中心となってオープンソースで開発しているWebアプリケーション向けテスト自動化ライブラリです。対応環境が幅広く柔軟で、精度の高いテストを特長としています。 具体的には、Chrome、Edge、Firefox、Safariの主要なWebブラウザのすべてを対象にしたテスト自動化が可能で、ヘッドレス、ヘッドありのいずれにも対応。モバイルエミュレーションを用いたAndroid版Google ChromeとMobile Safariのテストも、実
マイクロソフト、Webアプリテストの自動化サービス「Microsoft Playwright Testing」プレビューを開始 マイクロソフトは、Webアプリケーションのテスト自動化フレームワーク「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプライベートプレビューを開始すると発表しました。 テスト自動化フレームワーク「Playwright」 Playwrightは、マイクロソフトが中心となって開発しているオープンソースのWebアプリケーション向けテスト自動化フレームワークです。 実行環境、対象ブラウザ、対応言語が幅広く、テスト実行時にはWebブラウザの動作を自動的に待つ機能を備えるなど、柔軟で精度の高いテスト自動化が実現できる点を特長としています。 具体的には、デスクトップ向けのWebア
この記事では、Playwright の VSCode 拡張を使って GUI 操作のみでテストの記録や実行する方法について紹介します。 Playwright の VSCode 拡張とは? Playwright の VSCode 拡張は、Playwright の作成元である Microsoft が公式に提供している拡張機能で、VSCode 内で直接ブラウザテストの記録や実行を支援するための便利なツールです。 GUI 操作を中心に、テストの記録や実行を手軽に行うことが可能となります。 VSCode 拡張のインストールは、以下のリンクから行うことができます。 VSCode 拡張を活用してテストを書く 本記事では、シンプルな ToDo アプリを例にテストの作成方法を説明します。Playwright のインストール方法は、公式ドキュメントをご参照ください。その後、VSCode に Playwright
Playwrightの公式ドキュメントに「Best Practices」というページがあったので翻訳してみました。 原文: Best Practices | Playwright 目次 目次イントロダクションテスト哲学ユーザから見えるふるまいをテストするテストはできるだけ分離するサードパーティの依存関係をテストしないデータベースを使ったテストベストプラクティスロケータを使うメソッドチェーンとフィルタリングの使用XPath や CSS セレクタよりもユーザー向けの属性値を優先するロケータの生成codegen を使ってロケータを生成するVS Code 拡張機能を使用してロケーターを生成するウェブファーストのアサーションを使う手動でアサーションを使わないデバッグの設定ローカル環境でデバッグするCIでのデバッグPlaywrightのツールを使うすべてのブラウザでテストPlaywrig
はじめに Playwright を使うことで比較的簡単に E2E テストを実装することができます。しかし、通常テストコードは実装したら終わりということではなく、継続的にメンテナンス(保守)が必要になります。その際に保守しやすいように実装するため、Playwright の公式ドキュメントに記載されているベストプラクティスの中で参考になりそうな部分を確認しておこうと思います。 テストの独立性を高める 可能な限りテスト間の依存が無いようにして、テストを分離すると良いというプラクティスです。各テストが独立していることで、 1つのテストが失敗しても他のテストに影響しない テストの順序を考慮する必要がない テストをシンプルに保つことができる あたりのメリットがあるかと思います。また、特定の処理(例えば特定の URL に遷移する処理)の繰り返し実装するのを避けるために before and after
はじめに この記事では、 フロントエンドの開発において意義のあるテストはなにか? それらをコスパよく実現するためにはどうすればよいか? について考えて、作った構成を紹介します。 前提 下記の技術スタックを利用していますが、これ以外のスタックでも応用可能な仕組みが多いと思います。 Next.js Storybook playwright msw msw-snapshot (拙作) 注意事項 この記事の構成は、まだまだ実験的な機能だったり怪しい技術が一部採用されています。 msw-snapshot 拙作のライブラリであって、動作が怪しい可能性がめっちゃあります。 Next.js の testmode playwright + msw を実現するために必要でした。 まだまだ全然まともに動かないかもしれません。(サンプルリポジトリの単純なテストは動いた) サンプル 下記のリポジトリにサンプルを用意
新しい UI テストの手法を提供するテストライブラリ SafeTest 2024.02.25 SafeTest は Playwright と Jest/Vitest を組み合わせた UI テストライブラリです。特定のライブラリに依存せず、React, Vue, Angular, Svelte などのフレームワークに対応しています。SafeTest は単体テストと Playwright を使った E2E テストの手法を組み合わせることで、それぞれの手法が抱える欠点を補うことを目指しています。 SafeTest は Playwright と Jest/Vitest を組み合わせた UI テストライブラリです。特定のライブラリに依存せず、React, Vue, Angular, Svelte などのフレームワークに対応しています。 従来のフロントエンドのテストの手法は Testing Libra
こんにちは。カミナシにて業務委託としてフロントエンドを担当している田村(@junkboy0315)です。皆さんはフロントエンドのテスト、どのように取り組んでいますか?フロントのテストはなかなか難しいですよね。 バックエンドのテストには、「入力、出力、永続化されたデータ」の3つを検証するという基本セオリーがあります。しかし、フロントエンドのテストは、その粒度や手法が多様で、とっつきにくいと感じる方も多いのではないでしょうか。 カミナシでもフロントエンドのテストは以前は十分とは言えない状態でしたが、これまで継続的に改善を重ねてきました。今回は、その変遷についてお話ししようと思います。 夜明け前 カミナシのコードベースでは、元々ユニットテストがある程度整備されていました。これらは主に複雑な計算処理を行い結果を返す関数などに対して実施されていました。 しかし、画面全体の機能を網羅する包括的なテスト
こんにちは。SmartHR プロダクトエンジニアの sasaki (@s_sasaki_0529) です。 今回は、私が開発に携わっている届出書類機能における E2E テストを、Capybara + Selenium の構成から Playwright に移行し、開発プロセスに組み込んだお話をします。 扱う話題 E2Eテスト基盤を移行する具体的な背景と理由 移行における提案から、合意形成までの流れ 移行後の開発プロセスがどう変わったか 扱わない話題 Playwright など、記事内で扱う技術要素自体の詳細説明 移行作業自体の詳細 テストコードの設計・実装に関する具体的なテクニック なお、本記事では便宜上、移行前の E2E テストを「旧テスト基盤」移行後を「新テスト基盤」と呼称します。 届出書類機能について E2Eテストに限らず、テストというのはプロダクトの特性によって最適な手法は大きく変わ
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト(エンドツーエンドテスト)とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。
Introduction This guide should help you to make sure you are following our best practices and writing tests that are more resilient. Testing philosophy Test user-visible behavior Automated tests should verify that the application code works for the end users, and avoid relying on implementation details such as things which users will not typically use, see, or even know about such as the name o
重要なのはここで、 pw.webkit.launch() とするか pw.chromium.launch() とするかで 起動するブラウザが変わるだけです。 デバイスの設定も簡単 pw.devices に主な端末のviewport, UAの情報がまとめられています。 デバイスのリスト: https://github.com/microsoft/playwright/blob/master/src/deviceDescriptors.ts const pw = require('playwright'); // iPhone11のデバイス情報を取得 const iPhone11 = pw.devices['iPhone 11 Pro']; (async () => { const browser = await pw.webkit.launch(); const context = awai
はじめに なぜ VRT が必要なのか? VRTとは? Nx と Playwright で賢く VRT を実施する どう賢く実施したか 結果 まとめ 参考資料 はじめに 「食べログ ラーメン TOKYO 百名店」の全店舗訪問を目指してラーメン巡りを続けているフロントエンドエンジニアの kenshin です。 フロントエンド開発者の皆さん、新機能を追加したり、ライブラリをアップデートした後に UI が予期せず変更されてしまった経験はありませんか?このような問題を素早く検知し、未然に防ぐ方法として、ビジュアルリグレッションテスト(以下、VRT)があります。 この記事では、Nx と Playwright を用いて VRT を効率的に行う方法をご紹介します! なぜ VRT が必要なのか? フロントエンド開発では、新機能の追加やライブラリのアップデートにより、予期せぬ UI 変更が発生することがありま
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日は Playwright を使ったE2Eテストの導入について、紹介させていただきました。 今回は作成したテストをAWS 基盤上で動かす方法を紹介させていただきます。 前回の記事 tech.uzabase.com E2Eテスト実行のタイミング NewsPicksでは 下記のタイミングで E2Eテストを実行させています。 ①リリース時のカナリーデプロイ後 NewsPicks ではカナリーリリースを採用していてカナリーへのデプロイが完了した後、カナリーに向けてE2Eテストが動きます。 ②開発環境デプロイ後 動作確認をしたい場合に feature ブランチなどでデプロイ後 E2Eテストを実行できるようにしています。 本記事では主に 「②開発環境デプロイ後」 を例に紹介します。 実行方法 具
こんにちは!フロントエンドエキスパートチームの @mugi_uno です。 みなさんは Visual Regression Test は普段活用していますか? 昨今では事例もよく耳にするようになった印象です。一度使って手放せなくなった方もいるのではないでしょうか。 今回の記事では、通常のプロダクト新規開発とは異なる “脱レガシー” の文脈で Playwright を用いた簡易的な Visual Regression Test を試してみたので、導入に至る経緯と、どのように実施しているかを紹介します。 フロントエンドリアーキテクチャとサイレントリリース 現在サイボウズでは kintone のフロントエンドリアーキテクチャプロジェクトと称して、Closure Tools から React への脱レガシー作業が進行中です。プロジェクトの詳細については @koba04 が書いた次の記事をご覧くださ
Web アプリケーション開発での VRT 導入は、ちゃんと運用するとなると以下のような多くの検討事項を伴います。 Storybook のストーリーベースで比較するか?それとも実アプリケーションの URL ベースで比較するか? CI 上でアプリケーションをビルドして dev server を立ち上げるか、それともデプロイ先のアプリケーションにアクセスするか? スクリーンショットの比較はどのように行うか?比較時の閾値はどのように設定するか? 比較元のスクリーンショットはどのように用意するか?例えば Amazon S3 などのストレージ や GitHub Actions の actions/cache を使用する場合など コミットハッシュを用いて比較元のスクリーンショットを特定する場合、マージ先のコミットハッシュに紐づくスクリーンショットが存在しない時の対応は? VRT の結果で差分が出たが、そ
はじめに StorybookとPlaywrightを連携してテストすることで、思っていた以上に良い開発体験が得られたので紹介します。 今回の記事で紹介するテストは以下のリポジトリで公開しています。 具体的には以下の点が最高でした。 独立したコンポーネント開発 Storybookを利用することで、UIコンポーネントを独立して開発・テストできます。これにより、コンポーネントの再利用性が向上し、効率的な開発が可能になります。 シナリオベースのテスト Playwrightを使ってシナリオベースのテストを実行できます。これにより、ユーザーの実際の操作に近い状況でのテストが可能となり、アプリケーションの品質を高めることができます。 クロスブラウザテストの容易さ Playwrightは、複数のブラウザでの自動テストをサポートしています。これにより、異なるブラウザでの動作検証が容易になり、互換性の問題を効
npm init playwright@latest 実行すると @playwright/testがインストール playwrightの設定ファイル(playwright.config.ts)が追加 サンプル用のテストコードが追加 が行われます。 テストコード自動生成 playwrightにはブラウザ操作でテストコードを生成する機能があります。 package.jsonのscriptsに以下を追加してnpm run test:genするか、 "test:gen" : "playwright codegen" npxでも実行できます。引数のURLは任意です。 npx playwright codegen http://localhost:3000/
こんにちは、yebis0942です。 先日、@basemachina/bm-view-previewというツールをnpmで公開しました。ベースマキナのビュー機能のソースコードをローカル環境で編集しながら、Next.jsのnpm run devのようにライブプレビューで動作を確認できるツールです。 ライブプレビューはPlaywrightによってコントロールされたChromiumで表示しています。PlaywrightをE2Eテストや自動化以外の用途で使うのは珍しい事例かと思いますので、その背景と実装の裏側についてご紹介します。 ビュー機能とは ローカル環境で開発したい bm-view-previewの内部構成 ライブラリとしてのPlaywright ブラウザを人の手で操作できるようにする ウィンドウを表示する ウィンドウのリサイズに対応する ダイアログを自動で閉じない できなかったこと アプリ
As your web app matures, it becomes challenging to ensure your GUI doesn’t break with any given update. There are a lot of browsers and devices, and countless states for every one of your components. Unit tests ensure your code remains consistent, and E2E tests will ensure your system remains consistent, but neither will catch visual anomalies, layout issues, or platform compatibility issues. Ente
こんにちは、フロントエンドエンジニアのやなぎ( @apple_yagi )です。 先日、フロントエンドのIntegration Testで使用されていたCypressをPlaywrightに移行したので、その理由や実際に移行してみて感じたメリットなどをご紹介いたします。 なぜ移行したのか いくつか理由はありますが、大きな理由の1つとして Cypress は並列でテストを実行することができなかったことがあります。 Cypress で書かれた Integration Test はAPIリクエストを全てモックしているため、データベースの状態などにテスト結果が左右されることがなく、全てのテストを並列で実行可能でした。しかし、Cypressは並列でテストを実行することができず、テストを直列で実行するしかなかったため、テストの完了までに時間がかかってしまう問題がありました。
Web アクセシビリティに興味があったので、まず機械的なチェックツールから学んで知識を増やそうということでこのサイトに @axe-core/playwright と markuplint を導入してみました。 @axe-core/playwright のセットアップ 既に Playwright が導入されている状況を想定し進めます。まず@axe-core/playwright をインストールします。 pnpm add -D @axe-core/playwright このサイトの場合 VRT として Playwright を動かしているテストがあるので(過去資料)、そのプロセスに同居する形で axe を実行することにしました。 e2e.test.tsimport AxeBuilder from "@axe-core/playwright"; import type { Page, TestI
はじめに こんにちは。スペースマーケットでWebエンジニアしてます、新卒のdumbled0reです。 4月に入社してから早2ヶ月経って、入社式が昨日のように感じています。時の流れは早い。 日頃、ブラウザ操作する時はPythonのライブラリであるSeleniumを使用していましたが、vscodeにあるPlaywrightの拡張機能を使用すれば非エンジニアの方でも簡単にブラウザ操作用のコードを書けたので紹介します。 Playwrightとは PlaywrightとはMicrosoftが開発したオープンソースのE2Eテスト自動化フレームワークです。 Chromium、Firefox、WebKitなどの主要なブラウザで対応しており、1つのコードで複数のブラウザ上で動作確認も行えます。 環境 node 20.9.0 playwright 1.44.0 拡張機能のインストール 今回使用するVScode
はじめに 背景 やりたいこと Why MSW? 導入手順 詰まったこと defaultのtimeout設定時間が短い CIで落ちた時の検証方法がわからない 認証後のストレージの状態が入ってこない 今後の展望 おわりに はじめに enechainでフロントエンドエンジニアをしている@Shunya078です! 自分の所属するGXデスクでは『日本気候取引所 - Japan Climate Exchange』(以下JCEX)のサービス開発を行っており、その中でReactを使用したフロントエンドの開発を担当しています。 リグレッションテストは運用を考えると、設計から導入した後、どう管理していくかまで検討する点が多く存在します。 JCEXは去年の年末にリリースされたばかりのサービスで、まだブラウザまで含めたリグレッション相当になるテストレイヤーが導入できておらず、存在しませんでした。 今回は新たに自チ
こんにちは!estieでQAエンジニアをしているかすや(https://twitter.com/ma_cho29)です。 今回ブログを書くにあたり、前回書いたのはいつだったかなー?と見返すと1年が経過していたことに気がつきました。 歳を重ねると体感時間が短くなると聞いたことがありますがそれでしょうか・・・ 入社3年目になる今年もやり残しがないように過ごしたいところです。 さて、今回はQA未経験だった私が1人目のQAエンジニアとしてestieに入社し現在までおこなってきたE2Eテスト自動化の変遷について語っていきたいと思います。 私がメインで関わっているプロダクト「estie マーケット調査」は約2年間でテストフレームワーク移行を2度おこないました。 当時の意思決定やその際に個人的に感じたフレームワークごとのメリット・デメリットなど含めて話したいと思います。 (あくまで僕の所属する開発チーム
Playwright enables reliable end-to-end testing for modern web apps. Cross-browser. Playwright supports all modern rendering engines including Chromium, WebKit, and Firefox. Cross-platform. Test on Windows, Linux, and macOS, locally or on CI, headless or headed. Cross-language. Use the Playwright API in TypeScript, JavaScript, Python, .NET, Java. Test Mobile Web. Native mobile emulation of Google C
2020年は、突如Playwrightが現れ、Seleniumを置き換えるほどの勢いでいろいろなツールが現れました。 Puppeteerは、Playwrightが出てからもTypeScript化をしたりカスタムクエリハンドラ機能が実装されたりと、Chrome DevToolsプロトコルを利用するライブラリとして改善が続いています。 今年1年の Puppeteerのリリースページ https://github.com/puppeteer/puppeteer/releases Playwrightのリリースページ https://github.com/microsoft/playwright/releases を時系列にまとめてみます。 2020年1月。 PuppeteerとPlaywrightの15日間の演劇 https://speakerdeck.com/taminif/relation-
WebのクローリングにPuppeteerを使っています。 いつかPuppeteerの使い方をまとめたいなと思っていたのですが、そうこうしている内に月日は流れ、Puppeteerと同様のブラウザ操作ツールとして、Playwrightの名前をよく聞くようになってきました。 ならばいっそのこと、新たにクローラーを書く時はPlaywrightに乗り換えて、その使い方をまとめようかなと思い始めました。 一方、ブラウザ操作ツールとしてSeleniumも有名です。 Microsoft Power AutomateでSeleniumが使えると聞いたので、Seleniumならクローリングだけでなく、日々の業務の自動化にも使えて便利かなとSeleniumにも興味がありました。 SeleniumとPlaywright、どちらにしようかと迷ったのですが、どちらも使ったことがなかったので結局両方を使って確かめること
こんにちは。フロントエンド開発課所属のkoki_matsuraです。 今回はPlaywrightのコンポーネントテストについて個人的な意見を書いています。 目次は以下の通りになっています。 はじめに 導入方法 Playwright Component Test Runner のスゴい点 コンポーネントが実際にレンダリングされる 画面のサイズを指定できる タイムゾーンや言語を指定できる コンポーネントの振る舞いを見るテストに対応できる まとめ 参考 はじめに PlaywrightはMicrosoftが開発・メンテナンスしているCypress、Puppeteerなどと同じE2E自動テストフレームワークとして有名です。 playwright.dev Chromium、Edge、Firefoxなどの複数のブラウザに対応しており、全てに単一のAPIで簡単にテストの実装が可能になっています。 目玉機能
はじめに 2023年にZennチームにJoinしたdyoshikawaです。 このたびZennのE2Eテスト基盤をリプレイスしました。このような下回りの改善はユーザへの価値提供との距離が近い機能開発と比べてどうしても後回しになりがちな中、Publication Proという大きなリリースを迎えて少し開発が落ち着いたタイミングであり、E2Eテストを拡充できる土台を整えることで今後より安心して機能を追加していけるようにするために必要だということで実施しました。 各テストを独立実行可能にすることによる開発体験向上、CI(GitHub Actions)の実行時間短縮、そして将来を見据えてのCypressからPlaywrightへの移行を行いました。 本記事ではリプレイス前に抱えていた課題、それに対して打ち出した解決方針、そして具体的にどんなことをやったのかを紹介します。 抱えていた課題 前提として
こんにちは、JX通信社でシニアエンジニアをしているSirosuzumeです。 JX通信社の「FASTALERT」には、ユーザーが事前に設定した地域で発生した災害情報を、メールで受信する機能があります。 しかしテストする手順も複雑で、配信条件も多様化していったこともあって、手動でのテストを行うことに限界を感じていました。 設定画面の挙動確認など、ブラウザ上で完結するテストであればPlaywrightを使って自動化することもできていたのですが、実際にメールを受信するところのテストを自動化する方法についてのノウハウ不足が課題でした。 そこで、Amazon SESの機能を改めて確認していたところ、特定のメールアドレスで受信したメールをS3に保存する機能があることを知り、E2Eテスト内からS3にアクセスすることでメールの受信テストまで自動化でカバーできるのではないか、と考えたことが、今回のチャレンジ
CypressからPlaywrightに移行しました こんにちは、フロントエンドエンジニアのやなぎ( @apple_yagi )です。 先日、フロントエンドのIntegration Testで使用されていたCypressをPlaywrightに移行したので、... 前提 PR TIMESは、React + Vite製のアプリケーション(主に企業様の管理画面)とNext.js製のアプリケーション(SEOが重要なページ)が存在します。 本エントリーで紹介するのは、React + Vite製のアプリケーションに対するVRTとなります。 VRTの実行環境 VRT(Playwright)は公式のDocker Imageを用いて、Docker上で実行するようにしています。 { "scripts": { "_docker": "docker run --rm --ipc=host -v $(pwd):/
こんにちは!DOGO プロジェクトでソフトウェアエンジニアとして活動している @nissy_dev です。 DOGO プロジェクトでは、画面刷新を進めていく中で CI の実行時間が長く不安定になってしまい、開発生産性に大きな影響が出ていました。今回の記事では、CI の課題改善のために取り組んだことを紹介します。 目次 DOGO について CI を改善することになった背景 CI の改善のために取り組んだこと ビルド時に tsc を実行しない .next/cache を除いて、artifacts にアップデートする E2E テストをより多くの shard 数で分割する Playwright のブラウザのインストールをキャッシュする PR ではコード差分に関連するテストのみを実行する Hydration の挙動によってテストが flaky になっていた問題の解消 CI の改善の結果 今回取り組ま
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く