階層化自動テストで開発に機動力を

by ICKX

Slide 1

Slide 1 text

階層化自動テストで開発に機動力を同人ソフトサークル Project ICKX 若葉章 @effy_staffs (EFFY開発チーム)

Slide 2

Slide 2 text

自己紹介 • 若葉章（わかばあきら） • 2010年～同人ソフトサークル project ickx • プロデューサー / 営業 / インフラ / サーバサイド... / ゲームの実開発以外全部 • 本職はスタッフエンジニアっぽいこともするphpエンジニア • php続けてもうすぐ25年 php3の頃からお世話になっています • 最近の趣味は自転車とコーヒーとアマチュア無線 • tyrell iveで京阪や徳島から高松まで走ったり、icom ic-705やID-52で移動運用試したり • ボトルゲージ用のアルミステーやドリッパーホルダの自作を始めましたもうだめだ • Nintendo Switch で『VERTICAL STRIKE ENDLESS CHALLENGE』販売中 • Qiitaで『phpで高速に・省メモリ・確実に日本語csvを扱う方法』公開中 https://qiita.com/wakabadou/items/84b48ca12f25fb2fb69c 「composer require fw3/streams」をよろしくね。「composer require tacddd/tacddd」もよろしくね。「composer require bypassflow/crypt 」もよろしくね。

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

宣伝 PHPerKaigi2021で発表した「PHPでCSVを安心して扱うために」にて紹介した、SJIS CSVを直接扱えるライブラリ “fw3/streams “ 最新版にてZIPファイル内のCSVファイルを ”そのまま直接”扱えるようになりました。ぜひ使ってみてね。

Slide 6

Slide 6 text

こんな感じ。 CSVの設定はふつう NoRewindIterator万歳！！

Slide 7

Slide 7 text

宣伝最近、bypassflowと名付けたPHP8.4以降向けのライブラリ開発に着手しました。現在はcryptのみリリースしています。同じ条件でも毎回違う結果が出るのに適正に検証できるハッシュ同じ条件でも毎回違うバイナリが出力される暗号化処理来月あたりに強力なオブジェクトコレクションをリリースする予定なのでお楽しみに。

Slide 8

Slide 8 text

資料１ PHPカンファレンス関西2024やPHPerKaigi2024で発表した”「“品質”が高いコード」って何？”を読むとより理解が深まります

Slide 9

Slide 9 text

資料２ PHPカンファレンス新潟2025で発表した ”「兵法」から見る"質とスピード"”を読むとより理解が深まります

Slide 10

Slide 10 text

用語・原則

Slide 11

Slide 11 text

“テスト”

Slide 12

Slide 12 text

• リスクベースのアプローチの下で静的および動的技法を用いソフトウェアが仕様や要求事項を満たしていることを検証（Verification）妥当性確認（Validation）する一連のプロセス • 有限のテストケースによる実行や解析を通じて欠陥を検出し、品質情報を提供するもの ISO/IEC/IEEE 29119-1:2022で定義されるソフトウェアテストでは

Slide 13

Slide 13 text

“品質”

Slide 14

Slide 14 text

“品質”とは “対象”に“本来備わっている特性”の集まりが“要求事項”を満たす“程度” ISO 9000 (JIS Q 9000:2015)

Slide 15

Slide 15 text

ISO 25000で定義される “ソフトウェアの品質”では明示された条件下で使用するとき、明示的ニーズ又は暗黙のニーズを満たすためのソフトウェア製品の能力 ISO/IEC 25000:2014 (JIS X 25000:2017)

Slide 16

Slide 16 text

つまり“品質”とは “要求を満たしていること”

Slide 17

Slide 17 text

“高品質”

Slide 18

Slide 18 text

“高品質”とは • “定められた要求事項”に対して“要求を満たしている”ことです。 • 超過でも未満でもなりません。 • めっぽう忘れられがちですが、未満だけでなく、超過もダメです。

Slide 19

Slide 19 text

“高品質” を達成するには？

Slide 20

Slide 20 text

レイヤごとに要求を明確化しそれを達成する

Slide 21

Slide 21 text

単一責任原則

Slide 22

Slide 22 text

モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきである

Slide 23

Slide 23 text

開放閉鎖原則

Slide 24

Slide 24 text

ソフトウェア要素は、拡張に対しては開いており、修正に対しては閉じているべきである

Slide 25

Slide 25 text

テストにおける単一責任原則

Slide 26

Slide 26 text

テストは単一のスコープについて責任を持ち、その検証・妥当性確認をカプセル化すべきである

Slide 27

Slide 27 text

テストにおける開放閉鎖原則

Slide 28

Slide 28 text

テスト内容は階層の追加に対しては開いており、修正に対しては閉じているべきである

Slide 29

Slide 29 text

階層化自動テストで開発に機動力を

Slide 30

Slide 30 text

Webサイトを対象とした今までのテスト階層

Slide 31

Slide 31 text

• セッション・永続化を伴う複数URLへの一環した操作 • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストに対するレスポンス • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力

Slide 32

Slide 32 text

• セッション・永続化を伴う複数URLへの一環した操作 • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストに対するレスポンス • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力 E2Eでカバー xUnitでカバー

Slide 33

Slide 33 text

E2Eのカバー範囲が巨大すぎて出力に関係する変更があった場合膨大な修正が生まれる訳です

Slide 34

Slide 34 text

そもそもこれ “開放閉鎖原則” に即していないんですよね修正のたびに別階層に影響でる訳だし

Slide 35

Slide 35 text

これがあるので「E2Eは必ず破綻する」などと言われてきたわけです

Slide 36

Slide 36 text

テストを境界づけられたコンテキストとして整理します

Slide 37

Slide 37 text

そこで

Slide 38

Slide 38 text

テストの関心事をテストで見るべきもので分割する

Slide 39

Slide 39 text

• 状態 • 特定条件における出力内容を状態と定義します • テストとして関心事は特定条件における出力内容の妥当性 • テスト開始条件は固定され、結果には冪等性を要求します • そのため、前後URLなどのフローに関する内容は関知しません • フロー • 関連する複数の状態を横断するものをフローと定義します • テストとしての関心事は適切にフローを流せるか • その際のチェックポイントとして一部の状態をテストすることもありますが、チェックポイント以外の状態は関知しません

Slide 40

Slide 40 text

• フローとして見るべきもの • セッション・永続化を伴う複数URLへの一環した操作 • リクエスト受け付けから出力までの処理コールツリー • 状態として見るべきもの • 単一URLリクエストに対するレスポンス • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力

Slide 41

Slide 41 text

Slide 42

Slide 42 text

それは今まで通りのE2Eと xUnitでカバーしていた事では？

Slide 43

Slide 43 text

では別の関心事で整理してみます

Slide 44

Slide 44 text

テストの関心事を ”完結できる単位”で分割する

Slide 45

Slide 45 text

• 複数リクエストの集約が必要 • セッション・永続化を伴う複数URLへの一環した操作 • 単一リクエストで完結できる • 単一URLリクエストに対するレスポンス • 変数値の確認で完結できる • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力

Slide 46

Slide 46 text

フローとして見るべきもの状態として見るべきもの複数リクエストの集約が必要 • セッション・永続化を伴う複数URLへの一環した操作単一リクエストで完結できる • 単一URLリクエストに対するレスポンス変数値の確認で完結できる • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力マトリクスにするとこんな感じ

Slide 47

Slide 47 text

フローとして見るべきもの状態は強く意識せず、フローだけをテスト状態として見るべきものフローは意識せず、状態だけをテスト複数リクエストの集約が必要 • セッション・永続化を伴う複数URLへの一環した操作単一リクエストで完結できる • 単一URLリクエストに対するレスポンス変数値の確認で完結できる • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力関心事を”テストで見るべきもの”にした場合

Slide 48

Slide 48 text

フローとして見るべきもの状態は強く意識せず、フローだけをテスト状態として見るべきものフローは意識せず、状態だけをテスト複数リクエストの集約が必要 E2E以外では実現困難 • セッション・永続化を伴う複数URLへの一環した操作単一リクエストで完結できる状況によりE2E、xUnit使い分け • 単一URLリクエストに対するレスポンス変数値の確認で完結できる xUnitのみで完結できる • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力関心事を”テストを完結できる単位”にした場合

Slide 49

Slide 49 text

どこに注目する必要があってどのようにすればいいかを考えやすくなりました

Slide 50

Slide 50 text

また、テストを実施する手段を適材適所しやすくなりました

Slide 51

Slide 51 text

完結できる単位に注目するとテスト階層が見えてきます

Slide 52

Slide 52 text

テスト階層に期待される責務も明確になってきます

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

状況が整理された所でテスト階層の詳細を見ていきましょう

Slide 58

Slide 58 text

セッション・永続化を伴う複数URLへの一環した操作

Slide 59

Slide 59 text

• E2Eを適用せざるを得ない階層 • リクエストパラメータの管理や描画内容の検証を考えると、E2E以外での対応は非現実的 • なんでもできるから、なんでもやってしまうそのせいで地獄のメンテが発生します • そう思い込まれがちですね

Slide 60

Slide 60 text

このテスト階層に期待される責務は？

Slide 61

Slide 61 text

フローが妥当に流れること

Slide 62

Slide 62 text

• URLをまたぐフローにのみ関心を持ちます • URLごとの詳細な状態は他テスト階層で保証されます • 結果、フロー変更の影響を局限できます • MPAならとてもシンプルですね • 入力 => 確認 => 完了 => 結果確認の流れだけ • 入力で入れた内容が確認で出力され • セッションに入った内容が完了で反映され • 反映された内容が結果画面で確認できること

Slide 63

Slide 63 text

ここでの肝は各ページでの細かい内容の検証・妥当性確認を行わないことです

Slide 64

Slide 64 text

見るべきは妥当に遷移できたかどうかと遷移結果としてユニークな状態のみです

Slide 65

Slide 65 text

E2Eテストが爆発しがちだったのは、期待される責務であるフローが流れること以上のことを詰め込んでいたから

Slide 66

Slide 66 text

フローが流れるというのはビジネス上重要な価値を持つ処理が流れている事も指します

Slide 67

Slide 67 text

フローのみに関心を持てればビジネス上優先すべきテスト対象なのかで優先順位付けを行いやすくなるわけです

Slide 68

Slide 68 text

優先順位付けを行いやすくなるということは判断の迷いが弱くなり意思決定も速くできるため開発プロセスのリズムがよくなりテンポを速めることにつながります

Slide 69

Slide 69 text

では各URLごとの詳細な状態の確認はどうする？

Slide 70

Slide 70 text

適切な責務を担う階層に委譲しよう！

Slide 71

Slide 71 text

単一URLリクエストに対するレスポンス

Slide 72

Slide 72 text

• 一般にE2Eが適用される階層 • 負担感が爆増するのは大抵の場合ここのせい • 全体を通すE2Eで巻き取れてしまうため単体で実行する意味がない • そう思い込まれがちですね

Slide 73

Slide 73 text

このテスト階層に期待される責務は？

Slide 74

Slide 74 text

入力検証、出力・表示内容がブラウザ描画時点の内容として妥当であること

Slide 75

Slide 75 text

• そのURLで完結する表示状態にのみ関心を持ちます • フローや変数の状態は他テスト階層で保証されます • 結果、表示内容変更の影響を局限できます • 特定のHTTPリクエストに対して、妥当なレスポンスであるかを見ることで冪等性のあるテストをします • ページ遷移に伴う外乱がなく、純粋なリクエスト・レスポンスに関心を集中できます

Slide 76

Slide 76 text

単一URLリクエストにおける変数割り当て

Slide 77

Slide 77 text

• 一般にE2Eが適用される階層 • 負担感が爆増するのは大抵の場合ここのせい • レンダリングするんだからE2Eでなければだめ • そう思い込まれがちですね

Slide 78

Slide 78 text

このテスト階層に期待される責務は？

Slide 79

Slide 79 text

出力前段階として割り当てられている変数が妥当であること

Slide 80

Slide 80 text

• 描画に利用する変数の状態のみ関心を持ちます • フローやブラウザでの描画、変数生成手段は他テスト階層で保証されます • 結果、アサイン内容変更の影響を局限できます

Slide 81

Slide 81 text

レンダリングする内容、どうやって渡してますか？

Slide 82

Slide 82 text

一般的なフレームワークを利用している場合、 Renderインスタンスに直接変数アサインか View Modelオブジェクト経由が多いです

Slide 83

Slide 83 text

そう、この時点で変数なんですよつまりxUnit適用できるな？

Slide 84

Slide 84 text

今までE2Eに対応を強制していた検証内容をより早い段階へ委譲させることが出来ました

Slide 85

Slide 85 text

ストレージ以外の大がかりな実行準備を必要としないため、比較的軽率に実行出来るのも利点です

Slide 86

Slide 86 text

また、その気になればEC CUBE2などの旧いプロダクトであったとしても適用できる余地がありますというかやったあれはRender内でexitしてるのでそのあたりのつじつま合わせが大変ですが

Slide 87

Slide 87 text

単一URLリクエストにおける検証処理

Slide 88

Slide 88 text

• 一般にE2Eが適用される階層 • 他の階層で吸収されたり、されなかったりと曖昧になりがち • フォーム入力とブラウザ出力なんだから E2Eでなければだめ • そう思い込まれがちですね

Slide 89

Slide 89 text

このテスト階層に期待される責務は？

Slide 90

Slide 90 text

HTTPリクエストを入力値として値の文字列表現が受入仕様に対して妥当であること

Slide 91

Slide 91 text

• 入力値の文字列表現が受入仕様に対して妥当かどうかのみ関心を持ちます • フローやブラウザでの描画、変数生成・割当手段は他テスト階層で保証されます • 結果、受入仕様変更の影響を局限できます

Slide 92

Slide 92 text

ただし…

Slide 93

Slide 93 text

• 入力値検証処理のみを切りはがせる環境である必要があります • SymfonyならTypeTestCaseで検証できるが単一URL単位でのリクエストとして表現するのが手間

Slide 94

Slide 94 text

かつて私が提供した環境では RequestModelという概念を用意しそのリクエストが成立するために必要なこと全てが妥当であることを保証していました

Slide 95

Slide 95 text

リクエスト受け付けから出力までの処理コールツリー

Slide 96

Slide 96 text

• 他のテストが結果として巻き取っている階層 • 滅法バグが出る原因の一つ • 特に引数・返り値の変数型周り • インターフェースなり値オブジェクトなりで意味安全をガチガチに固めてあればPHPStan などで静的解析としてテストが可能に

Slide 97

Slide 97 text

このテスト階層に期待される責務は？

Slide 98

Slide 98 text

特定コード地点からの呼び出しフローが妥当に流れること

Slide 99

Slide 99 text

フローが妥当に流れること

Slide 100

Slide 100 text

• マーチンの開放/閉鎖原則をうまく適用できていると、インターフェースの呼び出しツリーをフロー、具象の関心事を状態として定義する事ができます • URLリクエストに対する関心事、具象の関心事は他テスト階層で保証されます • 結果、呼び出しツリーの変更の影響を局限できます

Slide 101

Slide 101 text

クラス・関数に対する入力と出力

Slide 102

Slide 102 text

• 一般にxUnitが適用される階層 • ここについては議論の余地がありませんね • テクニックとしてはJIG（治具）と見立て作業中のリグレッションテスト機能として割り切ると扱いやすくなります

Slide 103

Slide 103 text

このテスト階層に期待される責務は？

Slide 104

Slide 104 text

クラス・関数への入力が出力時に状態として妥当であること

Slide 105

Slide 105 text

• プログラミングインターフェースへの入力から得られる出力状態にのみ関心を持ちます • 呼び出しフローは他テスト階層で保証されます • 結果、クラス・関数の仕様変更影響を局限できます • 使われ方の特性上、限定条件に特化した検証を実施しやすいため、適切に作りこむと”追跡が面倒”な不具合を抑止しやすくなります

Slide 106

Slide 106 text

ここまでのテスト階層にないテスト対象が発見された場合は？

Slide 107

Slide 107 text

コンテキストが増えただけなので適宜増やせば宜しい

Slide 108

Slide 108 text

逆もまたしかりで例えばリクエスト検証処理は実装都合で事実上実現不能ならば減らしてしまえばいい

Slide 109

Slide 109 text

ただし、テストプロセスに対して要求される事項を誤って削らないよう注意が必要です

Slide 110

Slide 110 text

結びに

Slide 111

Slide 111 text

階層化自動テストとは • 境界付けられたコンテキストに応じてテストを分割する • テストの関心事を見るべきものと完結できる単位で分割する • テストで見るべきものをフローと状態に分割する • 階層テストはそれぞれ独立して機能する • 階層テストはプロセスに要求されるコンテキストの有無で増減する • ツールの謳う使い方に囚われない • 上記を満たし、実施される自動テストが階層化自動テストである

Slide 112

Slide 112 text

階層化自動テストを導入するメリット

Slide 113

Slide 113 text

• テスト範囲と責務の明確化 • 修正・メンテコストの低減 • 開発プロセスのリズム・テンポ向上

Slide 114

Slide 114 text

階層化自動テストを導入することでテスト対象が明確になるため高機能なテストを低負担で実現しやすくなります

Slide 115

Slide 115 text

• セッション・永続化を伴う複数URLへの一環した操作 • 単一URLリクエストに対するレスポンス • リクエスト受け付けから出力までの処理コールツリー • 単一URLリクエストにおける検証処理 • 単一URLリクエストにおける変数割り当て • クラス、関数に対する入力と出力画面遷移のみ担当画面描画のみ担当プログラムコールツリーのみ担当 HTTP入力検証のみ担当アクションが生成する変数のみ担当処理の入出力のみ担当

Slide 116

Slide 116 text

各工程において実施すべきテストを適切に局限できるため各工程で必要とされるテストをより早く完了させる事が出来ます

Slide 117

Slide 117 text

またいつそのテストが実施されるのか工程単位でここまでは保証済みが自明となるため業務プロセスのリズムを取りやすくなります

Slide 118

Slide 118 text

• セッション・永続化を伴う複数 U R L への一環した操作 • 単一 U R L リクエストに対するレスポンス • リクエスト受け付けから出力までの処理コールツリー • 単一 U R L リクエストにおける検証処理 • 単一 U R L リクエストにおける変数割り当て • クラス、関数に対する入力と出力リリース前受け入れ前 PR前コミット単位作業単位作業単位上書き保存単位テストプロセスフロー

Slide 119

Slide 119 text

おしまい

Slide 120

Slide 120 text

appendix データ設計

Slide 121

Slide 121 text

自動テストを設計するにあたり甚大な影響を与えるのがデータです

Slide 122

Slide 122 text

理想を言えば全てモックで完結できる簡潔なデータ設計になっていると良いのですがそんな都合の良い状況はあまりありません

Slide 123

Slide 123 text

現実としてはストレージを利用してテストした方が速いし正確とかあるある

Slide 124

Slide 124 text

現実に負けてストレージに依存するテストを設計する場合に問題になるのが初期化に莫大な時間を要求するマスタデータ

Slide 125

Slide 125 text

ECサイトならば不正住所情報

Slide 126

Slide 126 text

これに対する対処として DBを分割する選択肢があります

Slide 127

Slide 127 text

MySQLなら同一接続先内で別データベースを作るだけで対応できます仮にリレーションが必要だった場合 DB名.テーブル名で指定する事が出来ます