Webアプリ開発におけるE2Eテストとは？ ほかのテストとの違いやE2Eテストをどう利用すべきかを解説
WebアプリケーションにおけるE2E（End to End）テストとは、アプリケーション全体の機能をユーザーの観点からテストするプロセスです。E2Eテスト自動化の効果を高めるには、E2Eテストの特徴や目的、その他のテストレベルとの違いをきちんとおさえておく必要があります。特に、テスト対象が広範にわたる特性上、E2Eで何をテストするべきか、そして何をテストしないべきかの判断は重要な鍵を握ります。今回は書籍『テスト自動化実践ガイド』（翔泳社）から、E2Eテストの目的や価値、利用例について解説します。 本記事は『テスト自動化実践ガイド 継続的にWebアプリケーションを改善するための知識と技法』（著：末村拓也）の「第4章 E2Eテストとは何か」から一部を抜粋したものです。掲載にあたって編集しています。 E2Eテストの目的と責務 E2Eテストの特徴について、詳しく説明しておきます。もちろん、E2Eテ
UI のテストは AAA パターンより Given-When-Then パターンの方がしっくりくるかもしれない
UI のテストを AAA パターンで書いていて、ふと「render() って Arrange と Act のどっちだっけ？」と疑問に感じました。 この疑問から色々と調査した過程で「UI のテストは AAA パターンより Given-When-Then パターンを意識した方がしっくりくるのではないか」と感じたので、調査結果と一緒に紹介します。 AAA(Arrange-Act-Assert) パターンとは AAA パターンとは、テストコードを Arrange（準備）、Act（実行）、Assert（確認）の3つのフェーズに分けて記述する、テストコードを読みやすくするためのパターンのひとつです。それぞれのフェーズで記述する内容は次のようになります。 Arrange テストを実施するために必要となる前提条件や必要なデータを準備する テスト環境の初期化や依存関係（テストダブルも含む）の構築 テスト対象
Playwright を使いこなすためのベストプラクティス - Qiita
はじめに Playwright を使うことで比較的簡単に E2E テストを実装することができます。しかし、通常テストコードは実装したら終わりということではなく、継続的にメンテナンス（保守）が必要になります。その際に保守しやすいように実装するため、Playwright の公式ドキュメントに記載されているベストプラクティスの中で参考になりそうな部分を確認しておこうと思います。 テストの独立性を高める 可能な限りテスト間の依存が無いようにして、テストを分離すると良いというプラクティスです。各テストが独立していることで、 １つのテストが失敗しても他のテストに影響しない テストの順序を考慮する必要がない テストをシンプルに保つことができる あたりのメリットがあるかと思います。また、特定の処理（例えば特定の URL に遷移する処理）の繰り返し実装するのを避けるために before and after
StorybookとPlaywrightがもたらす画期的なUIテスト
はじめに StorybookとPlaywrightを連携してテストすることで、思っていた以上に良い開発体験が得られたので紹介します。 今回の記事で紹介するテストは以下のリポジトリで公開しています。 具体的には以下の点が最高でした。 独立したコンポーネント開発 Storybookを利用することで、UIコンポーネントを独立して開発・テストできます。これにより、コンポーネントの再利用性が向上し、効率的な開発が可能になります。 シナリオベースのテスト Playwrightを使ってシナリオベースのテストを実行できます。これにより、ユーザーの実際の操作に近い状況でのテストが可能となり、アプリケーションの品質を高めることができます。 クロスブラウザテストの容易さ Playwrightは、複数のブラウザでの自動テストをサポートしています。これにより、異なるブラウザでの動作検証が容易になり、互換性の問題を効
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
Playwrightを使ったE2Eテストを導入した話 - Uzabase for Engineers
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト（エンドツーエンドテスト）とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。
新しい UI テストの手法を提供するテストライブラリ SafeTest
新しい 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
Playwright を使用したエンドツーエンド テストの概要
エンドツーエンド テストの概要:Playwright。 Playwright は、Microsoft がオープンソースとして開発したエンド ツー エンド テスト用フレームワークで、モダンな Web アプリのテストに使用します。 この 6 部構成のシリーズでは、インストールから、テストの実行、記述、デバッグまで、関連するすべてを取り上げます。 Playwright を使うと、モダンな Web アプリに信頼性の高いエンドツーエンド テストを実行できます エンドツーエンド テストの概要:Playwright。 Playwright は、Microsoft がオープンソースとして開発したエンド ツー エンド テスト用フレームワークで、モダンな Web アプリのテストに使用します。 この 6 部構成のシリーズでは、インストールから、テストの実行、記述、デバッグまで、関連するすべてを取り上げます。 P
E2Eテストを Playwright で作り直して開発プロセスに組み込む話 - SmartHR Tech Blog
こんにちは。SmartHR プロダクトエンジニアの sasaki (@s_sasaki_0529) です。 今回は、私が開発に携わっている届出書類機能における E2E テストを、Capybara + Selenium の構成から Playwright に移行し、開発プロセスに組み込んだお話をします。 扱う話題 E2Eテスト基盤を移行する具体的な背景と理由 移行における提案から、合意形成までの流れ 移行後の開発プロセスがどう変わったか 扱わない話題 Playwright など、記事内で扱う技術要素自体の詳細説明 移行作業自体の詳細 テストコードの設計・実装に関する具体的なテクニック なお、本記事では便宜上、移行前の E2E テストを「旧テスト基盤」移行後を「新テスト基盤」と呼称します。 届出書類機能について E2Eテストに限らず、テストというのはプロダクトの特性によって最適な手法は大きく変わ
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
理想のフロントエンドテストをたずねて三千里 - カミナシ エンジニアブログ
こんにちは。カミナシにて業務委託としてフロントエンドを担当している田村(@junkboy0315)です。皆さんはフロントエンドのテスト、どのように取り組んでいますか？フロントのテストはなかなか難しいですよね。 バックエンドのテストには、「入力、出力、永続化されたデータ」の3つを検証するという基本セオリーがあります。しかし、フロントエンドのテストは、その粒度や手法が多様で、とっつきにくいと感じる方も多いのではないでしょうか。 カミナシでもフロントエンドのテストは以前は十分とは言えない状態でしたが、これまで継続的に改善を重ねてきました。今回は、その変遷についてお話ししようと思います。 夜明け前 カミナシのコードベースでは、元々ユニットテストがある程度整備されていました。これらは主に複雑な計算処理を行い結果を返す関数などに対して実施されていました。 しかし、画面全体の機能を網羅する包括的なテスト
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
フロントエンドのテストのモックには msw を使うのが最近の流行りらしい
皆様フロントエンドのテストを書いていらっしゃいますでしょうか？ フロントエンドのテストを書くときには API コールする処理を全てモックする必要があります。外部の API をコールする処理をテストに含めると API サーバーが落ちているなどの外部の要因によってテストが失敗してしまう可能性がありますし、テストを実行するたびに実際に API をコールしてしまうとサーバーに負荷がかかってしまうなど外部に対しても悪影響を与えてしまいます。 さて、従来のモックする手段としては Jest のモックを利用して axios や fetch などのモジュールをモック化する手法がよく使われていたかと思います。 最近のテスト手法として API コールをモックする際に Jest ではなく Mock Service Worker (以下 msw ）を使用する手法が注目されています。実施にどのように使用されているのか
cyber‑dojo.org
Yes, either individually or in a group training session. this video explains how to use it for individual practice: https://youtu.be/lIRF8MgyXho this video explains how to use it for group practice: https://youtu.be/OGGk-iFVOPQ It depends... Using https://cyber-dojo.org in a commercial organization requires a licence Non-commercial use is free, but please donate 100% of the licence fees and donati
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
Is TDD dead?
"TDD as One True Way" versus "TDD as devil-spawned tempter" is not a productive contrast. Most of us have similar goals for development: confidence, impact, challenge, belonging. Test-driven development is one path toward these goals, but there are many other paths. This conversation in six parts explores tradeoffs in development, places TDD in those tradeoffs, and gives you perspective with which
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Testing Trophy and Testing Classifications
spike and stabilize – Liz Keogh, lunivore
Let's Play TDD #110: Create a Beautiful, Simple Result - DZone Agile
Kent Beck