こんにちは。SEQ (Software Engineering in Quality)のzakiです。 これまで、freeeのE2Eテストは、Selenium、RSpec、Capybara、およびSitePrismを基盤とするRubyのテストを、Jenkinsを用いて実行していました。この構成にはいくつか課題があったため、現在は PlaywrightをベースにしたTypeScriptのテストを、GitHub Actionsで実行する新構成への移行を進めています。今回はその内、JenkinsからGitHub Actionsへの実行基盤の移行について紹介します。 従来のE2E実行基盤の構成とその課題 現在のE2E実行基盤図 (Jenkins) これまでのE2E実行基盤はEC2上にJenkinsを構築し、その中でE2Eテストを実行していました。しかし、この構成には以下の課題がありました。 テスト
この記事はenechain Advent Calendar 2024の21日目の記事です🎄 はじめに こんにちは。enechainでソフトウェアエンジニアをしている@nakker1218です。 私たちのチームでは、電力の取引仲介を行う同僚(ブローカー)たちが使う、注文の統合管理システムeNgineの開発しています。 ブローカーは日々1分1秒を争いながら収益を上げているため、システムが停止したり機能に不具合が生じると、事業に非常に大きな影響を与えてしまいます。 一方、電力業界はドメインが複雑で、要件や機能も多いため、バグが発生するリスクが高いです。 実際にこれまで以下のような問題が発生したことがありました。 Validな注文なのに、バリデーションが通らなくなった 特定の選択肢が選択されているときに表示されるはずのフォームが表示されない ショートカットキーを使ったインタラクションが一部正しく
Playwright の Aria snapshots はアクセシビリティツリーを比較することでテストする手法です。アクセシビリティツリーは DOM のスナップショットテストと比較して、外部から見た振る舞いが変わりづらいという利点があります。`.toMatchAriaSnapshot()` メソッドを使ってアクセシビリティツリーのスナップショットテストを行うことができます。 ソフトウェアテストの手法の 1 つに、スナップショットテストがあります。スナップショットテストは、テスト対象の出力を保存しておき、次回のテスト時に保存した出力と比較することで、テストが通ったかどうかを判断する手法です。フロントエンドのテストでは、特に UI のテストにおいてスナップショットテストがよく使われます。 コンポーネントのレンダリング結果の DOM 構造を保存しておき、次回のテスト時に保存した DOM 構造と比
はじめに StorybookとPlaywrightを連携してテストすることで、思っていた以上に良い開発体験が得られたので紹介します。 今回の記事で紹介するテストは以下のリポジトリで公開しています。 具体的には以下の点が最高でした。 独立したコンポーネント開発 Storybookを利用することで、UIコンポーネントを独立して開発・テストできます。これにより、コンポーネントの再利用性が向上し、効率的な開発が可能になります。 シナリオベースのテスト Playwrightを使ってシナリオベースのテストを実行できます。これにより、ユーザーの実際の操作に近い状況でのテストが可能となり、アプリケーションの品質を高めることができます。 クロスブラウザテストの容易さ Playwrightは、複数のブラウザでの自動テストをサポートしています。これにより、異なるブラウザでの動作検証が容易になり、互換性の問題を効
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
Web アプリケーション開発での VRT 導入は、ちゃんと運用するとなると以下のような多くの検討事項を伴います。 Storybook のストーリーベースで比較するか？それとも実アプリケーションの URL ベースで比較するか？ CI 上でアプリケーションをビルドして dev server を立ち上げるか、それともデプロイ先のアプリケーションにアクセスするか？ スクリーンショットの比較はどのように行うか？比較時の閾値はどのように設定するか？ 比較元のスクリーンショットはどのように用意するか？例えば Amazon S3 などのストレージ や GitHub Actions の actions/cache を使用する場合など コミットハッシュを用いて比較元のスクリーンショットを特定する場合、マージ先のコミットハッシュに紐づくスクリーンショットが存在しない時の対応は？ VRT の結果で差分が出たが、そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
