E2Eのテスト環境とテストデータの理想と現実 〜現実のシステムでE2Eテストを作り維持する工夫と具体事例〜 / real world e2e testing

PHPerが日々奮闘するソフトウェア開発の現場では、ユニットテストを書くことは推奨され普及してきました。
一方、E2Eといった高レベルのテストになると整備したいという気持ちはありつつ、初期構築コスト自体の高さや、構築したもののテスト維持に失敗する話をよく聞きます。
その要因の一つとして、本トークではテスト環境とテストデータに着目します。

テスト環境とテストデータの扱いは、既存システム都合との折衷案を取る必要があったりする理想と現実の間での戦いになる事が多いでしょう。
現場での戦いの武器となるような事例とそれぞれの実践手段のメリット・デメリットをまとめてお伝えします。

Transcript

1. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. E2Eのテスト環境とテストデータの 理想と現実 1 2021.05.29 PHP CONF OKINAWA 2021 @hgsgtk Kazuki Higashiguchi 〜 現実のシステムでE2Eテストを作り 維持する工夫と具体事例 〜
2. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当資料の”想い” 自動E2Eテストに取り組む際には、様々な懸案事項を考えることになる。 「本当はこうしたほうが良い気がする」が連鎖する。 テスト対象システムの現状を踏まえた適切な妥協点をつけないと永遠に「悩んで」終わって しまう。 当資料は自動E2Eテストに取り組んだ開発者が、懸案事項に対して出した解を泥臭 いものも含めて公開する。 「うちだったらこういうふうに応用できるかな？」など、目の前のシステム課題を考え る材料にしていただきたい 2
3. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. @hgsgtk Kazuki Higashiguchi Software Developer in Tokyo / BASE BANK, Inc. Engineering Manager 自己紹介 3 『みんなのPHP』(2020.12) Dockerアプリケーション開発実践ガイド > コンテナアプリケーションの設計セオリー 『Software Design 12月号』(2019.12) PHPにおけるユニットテストとCI/CD > ユニットテストの育て方 • 実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発 へ〜（PHPerKaigi2021） PHP Conference Okinawa 2020 Current Presentation • デザインパターンを出自から深く理解する（前夜祭Session） • 「割れ窓」を増やさないためのコード設計（本編LT） • PHPにおける独自例外設計を考える（懇親会LT）
4. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. E2E（エンド・ツー・エンド）テスト 4 • アプリケーションワークフローを最初から 最後までテストする • 実際のユーザーシナリオを再現すること で、システムの統合性やデータの整合性を 検証することを目的とする • アプリケーションがハードウェア、ネット ワーク接続、外部依存、データベース、お よび他のアプリケーションとどのように 通信するかをテストする ”End To End Testing: A Detailed Guide” by BrowserStack https://www.browserstack.com/guide/end-to-end-testing
5. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 自動E2Eテスト整備には、様々な懸案事項が存在 5
6. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 目の前のシステムに合った着地点の見極めが必要 6
7. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジェンダ 7 テスト作成・実行の仕組みを選択する １ 2 SUT動作環境とテスト実行環境 3 テストデータをどう作るか 4 まとめ １ 2 3
8. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 用語説明: SUT(System Under Test) 「テスト対象システム」を指す ISTQB Glossaryの定義 “テスト対象となるシステムのことであり、テ スト対象の一種。” SUT at XUnitPatterns.comの定義 "Whatever thing we are testing" 8 E2EテストにおけるSUT
9. © 2012-2021 BASE, Inc. 9 1. テスト作成・実行の仕組み を選択する
10. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テスト作成・実行の仕組みを選択するためには 10 仕組みの選択は「どういうテストをしたいのか」に依存する。アジャイルテストの4象限を分 類軸に考察するとよい。 10 http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1 2. Lisa Crispin氏・Janet Gregory氏によって「ア ジャイルテストの4象限」と命名された （『Agile Testing』2009） 1. Brian Marick氏による4象限の分類(2003) ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』(2019年)の定義に準拠 『テスト駆動開発』付録C での解説より https://www.amazon.co.jp/dp/4274217884
11. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. アジャイルテストの四象限 テスト活動を2つの軸で分類した 1. 技術面 or ビジネス面 a. プログラマの領域の言葉で説明される b. ビジネスの専門家が興味を持つような言葉で説 明される 2. 開発チーム支援 or 製品批評 a. 開発チームを支援するテストは、コーディング 前・進行中に作成され、欠陥の防止に役立つ b. 製品を批評するテストは、コーディング完了後 に行われ、欠陥の発見・欠落したフィーチャの 特定に役立つ 11
12. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 各象限におけるテスト Q1: 技術面 && チーム支援 - コードレベルのテスト - 自動化 Q2: ビジネス面 && チーム支援 - 顧客視点の高レベルのテスト - 自動化・手動を組み合わせる Q3: ビジネス面 && 製品批評 - ユーザー受け入れテストや探索的テスト...etc - 手動で行われるものが多い Q4: 技術面 && 製品批評 - パフォーマンステスト・セキュリティテスト....etc - ツールによる実施 12 ※ 4象限内の要素は『Agile Testing Condensed: A Brief Introduction』(2019年)の定義に準拠
13. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. あなたが求める “E2E” はどれ？ 13 どの領域でのテストを考えていたかによって特性が変わってくる。 Q1: Code levelでの開発者の関心をテストできる - 特にプログラマがテストを書きやすいこと - ローカル開発環境で実行できる体験 - システム異常系の再現といった例外系のニーズも強くなる Q2: 顧客視点でのテスト記述と頻繁な実行 - プログラマ・テストエンジニア・仕様定義者が書きやすい - 顧客視点で確認したい機能性をE2Eで統合的にみたいニーズが強い - シナリオベースでのテスト作成 Q3: 製品批評の一部自動化 - 本番環境テストなど定期的に本番システムをテストしたい（ex. New Relic Synthetics） Q4: 品質特性ごとのテスト要件 - 「パフォーマンステストであれば、本番同等環境を非定期に実行できればよい」といった テストごとのテスト要件
14. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. チームでの導入の場合は「どの領域でE2Eテストをし ようとするか」を明らかにしないと話がすれ違うので 要注意。 当事例では、顧客視点での仕様・受入条件をテストを 通じて明確にしたいのが目論見だった（※1） 。ゆえにQ2 にフォーカスして以後の「選択・判断」を行った。 Q2の特性に基づき以下を決定する。 1. 仕様を記述・実行するテスティングフレームワーク 2. テスト自動化実装であるブラウザ自動テストツール どの領域をカバーしたいかを明らかにする 14 ※1 詳細の背景解説は『実践ATDD 〜TDDから更に 歩みを進めたソフトウェア開発へ〜』を参照 Q2: 顧客視点でのテスト記述と頻繁な実行 • プログラマ・テストエンジニア・仕様定 義者が書きやすい • 顧客視点で確認したい機能性をE2Eで統 合的にみたいニーズが強い • シナリオベースでのテスト作成
15. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テスティングフレームワークを選択する 15 有名なBDDツール Gherkin Syntaxをサポート https://cucumber.io/ ThoughtWorks社がメンテしている Go製の受け入れテスト自動化フレー ムワーク https://gauge.org/ A php framework for autotesting your business expectations. https://docs.behat.org/en/latest/ 弊チームで使用しているTool • Markdownベースのシンプルな仕様記述Syntax • ステップ実装のための言語は Java/JS/TS/Python/Ruby/C# をサポートしている • メンテナンスが活発（Issueをあげたら数分後に返事が来た） • Visual Studio Codeの拡張 ◦ （新規PJ作成・テスト実行・コード補完・定義ジャンプ・フォーマット...etc） Uncle Bob氏により作成された Wikiで記述する http://fitnesse.org/FrontPage 顧客視点のシナリオテストの作成・実行の仕組みを用意するため、受け入れテスト自動化ツールを見回った。
16. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 16 gaugeのテスト記述・実装構造
17. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. gaugeの実行・結果イメージ 17 2. 実行結果 1. VSCode上で実行 3. 結果レポート表示 *.spec
18. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 補足: gaugeのSpecificationのSyntax 18 Markdown-likeなSpecification Syntax # Specification 仕様、xUnit系でのテストクラスに該当 * Contexts step 前処理、xUnit系でのSetUpに該当 ## Scenario 個別のテストシナリオ、xUnit系ではテストメソッド * Step テストシナリオ内で実行するステップ ___ 後片付け、xUnit系でのTearDown 定義後のStepは後片付け処理として実行される
19. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 補足: Specファイル内のstepを実装する 19 example.spec • *.spec で定義したステップを選択したプログラミング言語で実装する • merit: 「現状のUI自動化実装の都合」と「本当にテストしたい仕様」 を切り離して考えられる ◦ ex. placeholderやid・classで要素を特定するのは「実装の都合」 API Client実装 webdriver selenium Pythonの場合は @step() でマッピング JavaScriptの場合は step() でマッピング
20. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ブラウザ自動テストツールを選択する 20 • microsoft/playwright https://playwright.dev/ • Chronium, Firefox, WebKit, Microsoft Edgeブラウザ操作を自動化するAPIを提供している Node.jsライブラリ • GUI操作を記録してコード生成する Inspector というツールの体験が良い • Pupetteer https://pptr.dev/ • Google製のChromeまたはChromiumを制御するためのAPIを提供しているNode.jsライブラリ • TAIKO https://taiko.dev/ • ThoughtWorks社がメンテナンスしているブラウザ経由のテストを行うためのNode.jsライブラリ • コマンドでSUTを操作した記録を元にコードを生成する • gaugeとの組み合わせを意識している • cypress https://www.cypress.io/ • cypressを使っていなくてもBest Practicesのページは参考になる https://docs.cypress.io/guides/references/best-practices その他...
21. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ブラウザ自動テストツールの選択結果 21 Playwright • シンプルかつ抽象度の高いAPIで使いやすい • Inspectorで生成されたコードを使って清書するようなテスト作成体験 ◦ UIテストは変更に弱いが、壊れても再度変更後のGUI操作で復旧できる期待 • 公式ドキュメント内の情報量・サンプルコードも多い、Frontend界隈での注目度も高い TAIKO • より Easy よりなAPIでHTMLの詳細への依存度が低いテストコードを作りやすい ◦ 相対的な位置関係からよしなにHTML要素を見つける ex. write(textBox("first name", toLeftOf("last name")) • gauge同様ThoughtWorks社がメンテナンスしていることもあり、「受け入れテストツール」での利用をより意 識されている（所感） • 相対的にマイナーではあるため、情報量は少ない 2つのSUTに対して playwright と taiko を使っているが、playwrightのほうが優勢（所感）
22. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 補足: Playwright Inspector の体験 22 Playwright InspectorでUI操作 操作した過程がコードとしてレコーディングさ れる 生成されたコードを組み合わせてステップ実 装を行う
23. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 補足: TAIKOによるCUI上での試行錯誤支援 23 TAIKO ではCUI上でブラウザ操作する機能 が搭載されている > openBrowser() // ブラウザを開く > goto('https://fortee.jp/') // URLアクセス > click('PHPerKaigi 2021') // クリック > click('ログイン') 逐次的にAPIを試してテスト自動化コードを 作成する
24. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テスト作成・実行の仕組みを選択するためには 24 • テストの仕組みを考える際には、アジャイルテストの4象限を分類 軸に使いつつ、「どういうテストをしたいのか」スタンスを明確 にするべし • 「Q2: ビジネス面 && チーム支援」の分類内容だった場合には、 当資料内のgauge + playwright/taikoの選択肢を参考に
25. © 2012-2021 BASE, Inc. 25 2. SUT動作環境とテスト実行環境
26. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. SUT動作環境の選択肢 26 1. CI環境内に自動テスト専用環境を構築する a. 完全にCI Job専用の環境になりテスト実行結果は安定し やすい a. 複数APIで構成されるようなシステム構成の場合、構築難 易度は高い b. 依存APIをモックするような単一 “component tests” の場 合は有力な選択肢 2. 自動テスト専用のサーバーを用意する a. コストとの兼ね合い b. 実際のデータベースを用意するか？既存デプロイパイプラ インへの組み込みの工数 3. 検証用環境で自動テストを実行する a. ミニマムに始めることができる b. 手動でのテストに自動テストが影響を受けうる、flakyなテス トになるリスク
27. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. “One or more tests are behaving erratically; sometimes they pass and sometimes they fail.” http://xunitpatterns.com/Erratic%20Test.html xUnit Test Pattern(xUTP)では同様の概念をErratic Testと表現する 用語解説: flaky “We define a "flaky" test result as a test that exhibits both a passing and a failing result with the same code.” Google Testing Blogによる定義 https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html 27 同じコードで通ったり落ちたりするテスト
28. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. CI専用環境のほうが理想的である 手動テスト専用環境と自動テスト環境を混ぜた場合、テスト失敗時の切り分けが難しくなる リスクを背負う（バグなのか不安定なのか手動テストの影響を受けたか） 一方で、E2EレベルのCI専用環境はリソースコスト・構築工数の観点で始めにくい 28 Set up a dedicated continuous validation environment（専用のCI環境を構築せよ） “Many teams tried to use the same environment for demonstrating features to business users, manual testing, and continuous validation. This regularly caused data consistency issues. Without a dedicated environment, it’s hard to know whether a test failed because there’s a bug, whether someone changed something on the test environment, or whether the system is just unstable” 『Specification by Example』 Chapter 10. Validating frequently より私訳
29. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 検証用環境で自動テストを実行する 29 • 当資料内の事例では「3. 検証用環境で自動テストを実行する」を選択 ◦ それなりに大きなシステムの新規構築は結構大変 ◦ 手動テストに影響を受けうる問題は「テストデータの作り方」で対策す る（後述） • テスト実行環境から、毎リリースごとにデプロイされる「検証環境」に対し て、自動テストを実行する ◦ 定期的に実行され続けることがテストのメンテナンスにおいて重要 （E2Eレイヤのテストは書き捨てられがち） • 実行トリガー ◦ 受け入れテストコードの更新時 ◦ cronで日次の定期実行 • デプロイパイプラインまで自チーム内で構築しているAPI Serviceについ てはCI/CD Pipelineに自動テスト実行を組み込んでいる（※1） ※1 実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 内の「付録A. CIでのテスト実行基盤事 例」を参照
30. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. ローカル開発環境での実行をサポートする 30 ※ 検証環境用のデータをローカルにdump importする構成はテスト環境を作るためのものではなく 既存の仕組みにたまたま乗っかった
31. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. SUT動作環境とテスト実行環境 31 • CI専用環境を用意するのが理想だが、対象システムのアーキテク チャの複雑さに比例した難しさ・工数が発生する • デメリットを踏まえた上で手動テスト用の検証環境と併用する選 択肢は非常に現実的 • 不安定の火種になりやすいテストデータの作り方については次章 にて
32. © 2012-2021 BASE, Inc. 32 3. テストデータをどう作るか
33. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テストデータを作る方法・タイミング 33 1. テスト環境に手動でデータを用意しておく a. 実際のシステムを通じて作られた正しいデータが用意 できる b. テストシナリオとデータの関係性が暗黙的になりわか りづらくなる i. ex. ID=1のショップを使う（なぜ？ 2. 毎Scenarioごとにデータを作成・調整 a. テストシナリオ内で「どういうデータが必要なのか」 が明示されわかりやすい b. 環境差異の影響を受けにくい c. E2Eにおいて自動でデータが用意できないこともある i. ex. SMS認証をしたショップを用意しよう d. テスト速度が低下する i. ex. 毎回ネットショップを開設すると？ テストシナリオのためのデータセットアップタイミングはいくつか存在する。
34. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テスト環境に手動でデータを用意するケース • 検証環境において、ユーザーを事前作成するケースはテスト自動化界隈でもよく 取られている（筆者観測範囲内） ◦ 検証環境で手動テストと自動テストが両方行われる分、自動テスト専用アカウン トを作ることで相互に影響を与えるのを回避する • 当資料の事例でもいくつか事前にユーザーを作成している 34
35. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 毎Scenarioごとにデータを作成するケース • SUTのAPIやUIを通じてデータを作成できるのであれば、テストの保守性上望ましい ◦ ドキュメンテーションとしてのわかりやすさ, テスト環境の状態に対して影響を受けにくい ...etc • Case Study: Web APIのシナリオテスト（YELL BANKで資金調達する） 35 『YELL BANK（エールバンク）』資金調達をリスクなく、一瞬で。 https://thebase.in/yellbank gaugeにはシナリオ内でデータを伝搬させる方法として DataStore という機構が用意されている
36. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 個別Issue: 副作用をSUTを通じて解消できない • 事前に作成したデータに対して副作用のあるテスト操作を行うが、その副作用の解消はSUT自身ではできない ケースが有る 36 ※ ヘルプ | BASE ショップ向けヘルプ 振込申請について > 振込申請とはなんですか？ https://bit.ly/2SzvmTh ※ ヘルプ | BASE ショップ向けヘルプ 振込申請について > 口座や金額の変更・申請のキャンセルをすることはできますか？ https://bit.ly/3hZXr0H ※ ヘルプ | BASE ショップ向けヘルプ 振込申請について > 振込申請時に必要なことはなんですか？ https://bit.ly/3c0MckH Case Study: 振込申請（※1）の振込先口座名義変更 • 振込申請内の振込先口座名義にたいして本人確認ができない場 合、自動案内メールを送信、ショップに口座情報を訂正しても らうシナリオが存在する。 • 口座情報訂正はショップ向けシステム（SUT）が行うが、その後 副作用を解消するような操作は、裏側の「管理システム」を通 じて行われる ※1 BASEではショップに対して購入者が支払った商品代金を一旦預かる ショップが「振込申請」することで、ショップの銀行口座にBASEが振り込みを行う
37. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. “Unrepeatable test” という不安定さ 37 Erratic test(=Flaky)の一種が “Unrepeatable test” である 一回目の実行とそれ以降の実行が変わりうる テストデータを事前準備する方法をとった場合には、工夫してこの現象を回避する 必要がある “A test behaves differently the first time it is run than how it behaves on subsequent test runs.” http://xunitpatterns.com/Erratic%20Test.html#Unrepeatable%20Test
38. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. SUT自体のAPIを使用してフィクスチャを設定、結果を検証することが通常のアプ ローチだが、前述したとおりシステム仕様等の状況によってはそれが難しいor望ま しくないケースがある。 バックドアを利用してフィクスチャを設定したりSUTの状態検証する方法を Back Door Manipulation と呼ぶ。 Back Door - テストデータベースへのアクセス - 依存コンポーネントのテストダブルへの置き換え xUTP Test Strategy: Back Door Manipulation 38 http://xunitpatterns.com/Back%20Door%20Manipulation.html
39. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. E2Eにおける Back Door Manipulationの手段 直接データベースにアクセスしてデータを作る Backdoor は以下の理由で策として 取りづらい。 • サービスのネットワーク構成上、一般的にRDBMS等はprivateで直接アクセスしにくい • E2Eなテストシナリオを回すために必要な関連テーブルは多い ◦ それなりに大きく歴史のあるシステムだと、ユーザーを作るだけでもかなりのテーブル数が関連する、デー タの正しさも担保しにくい SUT以外にも別システムが同一データベースを使っているケースは多い。 他システムもデータ準備・調整の Back Door として用いるアイデア 39
40. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. E2Eにおける Back door setup SUT上の機能ではカバーできないテストデータを、別システムを Back Door として 事前条件を整える 40
41. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 個別Issue: Unrepeatable testを避けにくい 41 システム仕様上、副作用を解消しきれないような機能も存在する。 Case Study: 一日一回の制限がある振込申請 • 振込申請は１ショップが1日につき申請できるのは1回までである • 毎テストケースで振込申請ができるテストショップを作るのは自動化しきれない 要素があり難しい 避けるべきこの”Unrepeatble test”も、E2Eレイヤだと一定要件で発生がやむおえ なくなるシーンが有る ヘルプ | BASE ショップ向けヘルプ 振込申請について > 振込申請に回数や金額の制限はありますか？ https://bit.ly/3vxKEX3 ヘルプ | BASE ショップ向けヘルプ 振込申請について > 振込申請時の電話番号認証は必須ですか？ https://bit.ly/3fOuPVu
42. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 副作用と制約を受け入れた定期実行プランを用意 42 テストシナリオショップで一日一回のdaily実行でのみ回し続ける対応にした `daily` tagを付けることでこのテストシナリオは日次の定期実行のみで自動実行 される all testsで実行するコマンド $ gauge run --tags "!draft & !manual & !daily" --env=ci specs // dailyタグがついてるテストは 実行されない
43. © 2012-2021 BASE, Inc. 43 まとめ
44. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 当資料の”想い”（再掲） 自動E2Eテストに取り組む際には、様々な懸案事項を考えることになる。 「本当はこうしたほうが良い気がする」が連鎖する。 テスト対象システムの現状を踏まえた適切な妥協点をつけないと永遠に「悩んで」終わって しまう。 当資料は自動E2Eテストに取り組んだ開発者が、懸案事項に対して出した解を泥臭 いものも含めて公開する。 「うちだったらこういうふうに応用できるかな？」など、目の前のシステム課題を考え る材料にしていただきたい 44
45. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. 例外テストを避けよう 45 当資料でみてきたとおり、テストデータとテスト環境の問題からE2Eレイヤでのテストはバリ エーションを扱うのが得意ではない。ユニットテストも活用しながらテストピラミッドのバラン スを取るようにしましょう。 “Try to avoid Exception Testing: E2E Testing is best used to test common user scenarios. When it comes to exceptional user scenarios, use integration testing, or low-level unit testing.” BrowserStackの”End To End Testing: A Detailed Guide”内の解説より https://www.browserstack.com/guide/end-to-end-testing
46. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テストピラミッド Mike Cohn氏が提唱した概念 (『Succeeding with Agile: Software Development Using Scrum』2009年） 『martinfowler.com: The Practical Test Pyramid』では、 テストピラミッドから学ぶべき点は次の2つだと言っている 1. 異なる粒度のテストを書く 2. 高レベルになるほど、持つべきテストは少なくなる 46 『Succeeding with Agile: Software Development Using Scrum』 https://www.amazon.co.jp/dp/B002TIOYWQ martinfowler.com: The Practical Test Pyramid https://martinfowler.com/articles/practical-test-pyramid.html ※ ”UI Tests”などのテストレイヤーは現在のテスト状況に対してシンプルすぎるため、 それらに固執する必要はなく、自分たちのプロダクト・開発チームに沿ったレイヤー 名で良いと指摘している
47. © 2012-2019 BASE, Inc. © 2012-2021 BASE, Inc. テストピラミッドを登ろう ほとんどの開発チームはユニットテストから始める そして「アイスクリームコーン」にならないように、 必要に応じて上の階層に登っていく （『初めての自動化テスト』著者 Jonathan Rasmusson ） 47 アイスクリームコーン 実行時間がかかり壊れやすい高レベルテストのほうが多く なってしまうアンチパターン ※ すべてのアイスクリームコーンが悪いわけではない （ex. そもそもテストが存在しないレガシーシステムでUIテストから始める） Testing is Good. Pyramids are Bad. Ice Cream Cones are the Worst / Stephen H Fishman https://medium.com/@fistsOfReason/testing-is-good-pyramids-are-ba d-ice-cream-cones-are-the-worst-ad94b9b2f05f https://www.oreilly.com/library/view/the-way-of/9781680502 251/f_0065.xhtml
48. © 2012-2021 BASE, Inc. Thanks