概要

通常の実行時検証には、manage_studioの構造化Test Sessionを使用します。AIはJSON-compatibleなscenarioを順番に実行し、各stepのtarget、期待値、観察値、所要時間、エラーを記録します。テストコードをScriptとして注入しません。

DashboardのPlaytestページはTest ValuesとAutomated Test Resultsに分かれています。Automated Test Resultsは保存済み結果のviewerであり、実行中のテストを制御したり、結果を再判定したりしません。

テスト値の観察と変更

Test Valuesタブでは、実際のStudio値を再利用可能なテストプロファイルに登録し、PlayまたはRunの実行中に現在値を観察して入力値を適用できます。

Playtest Test Values — 実行中のStudio値の観察と変更

Add valueでStudio selectionを選ぶと、Explorerの現在の選択からAttribute、Value、対応propertyを読み取り、テストコードを追加せずに登録できます。直接選択できない内部状態には、登録済みのTest Adapterを使用します。

PlayまたはRunを開始すると、Observed valuesに読み取り専用の現在値が表示されます。Change valuesでは入力値を手動で適用するか、入力確定時に自動適用できます。入力値と保存済みデフォルト値は別に保持され、Apply saved defaults when Play startsを有効にすると、次回のPlay開始時にプロファイルの保存済みデフォルト値が適用されます。

デフォルトの検証方法

modeを省略するとPlayモード(F5)で開始します。
v1は1 clientと順次stepをサポートします。
UI、入力、LocalScript、PlayerGui、LocalPlayerの検証にはPlayモードを使用します。
Runモード(F8)はclient観察が不要なserver、world、physics検証だけに使用します。
1つのsessionでclient UI、interaction、server結果を個別に検証できます。

"PlayモードでショップUIの表示を確認し、購入ボタンを実際の入力で押して、
サーバー側の購入結果まで検証して"

AIはtest_session_startでsessionを開始し、test_session_statusで進行状況とstep evidenceを確認します。実行中のsessionをキャンセルする場合はtest_session_stopを使用します。

UIと入力を検証する

wait_for_guiで対象UIを待ちます。
snapshot_guiで名前、class、表示状態、位置、サイズ、ZIndex、text要約を記録します。
input_clickでviewport内のボタンにVirtualInputを送ります。
入力送信とGuiButton.Activatedの観察を別々のevidenceとして記録します。
必要に応じて、別のserver stepでゲーム状態の変化を確認します。

構造化session v1はPlayモード中のviewport pixel screenshotをサポートしません。Playモードの確認にはsemantic UI snapshotとinteraction evidenceを使用してください。manage_camera.screenshotはEditモード専用です。

Dashboardで結果を確認する

Test Historyには構造化sessionと既存のRaw Luau記録が表示されます。

項目	説明
実行種類	`Structured`または`Raw Luau`
Status	`passed`、`failed`、`timed_out`、`cancelled`、`insufficient_evidence`
Mode	PlayまたはRun
Duration	テスト全体の所要時間
Evidence要約	server/client agent数と主な失敗または制限

構造化reportでは、全体判定、Server・Client UI・Interaction・Visual dimension、stepごとのexpected/observed/evidence/error、Agent capability、保存artifactを確認できます。

必須evidenceがすべて成功した場合だけ全体結果がpassedになります。Server結果が成功しても、必須のclient UIまたはinteraction evidenceがなければinsufficient_evidenceです。optional observationの失敗は記録されますが、成功した必須検証を失敗に変えません。

Playtestを手動で制御する

Action	説明
`play_start`	Play(F5)またはRun(F8)を開始
`play_stop`	現在のPlaytestを停止
`play_pause`	実行中のPlaytestを一時停止
`play_resume`	一時停止したPlaytestを再開
`play_status`	現在の`edit`、`running`、`paused`状態と可能なactionを取得

構造化Sessionのaction

Action	説明	主なパラメーター
`test_session_start`	scenario検証後にbackground sessionを開始	`scenario`、`idempotencyKey`、Studio selector
`test_session_status`	状態とbounded step evidenceを取得	`sessionId`、`stepCursor`、`stepLimit`
`test_session_stop`	sessionのキャンセルとteardownを要求	`sessionId`

test_session_statusは標準で20件、最大50件のstep evidenceを返します。次のページにはresponseのopaque stepCursorを使用します。

Raw Luau診断

run_testは引き続き利用できますが、通常の検証のデフォルトではありません。プロジェクト固有のLuau assertionなど、raw scriptが必要な高度な診断で明示的に選択します。

run_testはscriptをServerScriptService.__MCP_TestRunnerへ注入し、log signalを収集してPlaytestと一時scriptをクリーンアップします。

保存される結果

結果は選択したPlaceの{projectRoot}/weppy-project-sync/place_XXXXX/tests/YYYYMMDD-HHmmss/に保存されます。

test-result.json   # 全体判定とstep evidenceの正本
test-report.md     # 人が読む要約
test-log.txt       # server/client originを含むログ
test-context.json  # 実行contextとreplay metadata

既存のRaw Luau記録はMarkdown reportとlog形式のまま読み取れ、自動変換されません。

Multi-Place検証

複数のPlaceを変更した場合は、DashboardのConnectionページでStudio IDとPlace名を確認してから対象ごとに依頼します。構造化sessionは開始時に選択したStudio targetを固定し、実行中にactive Studioが変わっても別のPlaceへ移動しません。

失敗原因を確認する

Dashboardで失敗したreportを選び、全体理由とfailed stepを確認します。expected、observed、error、evidence dimensionを比較すると、UI未表示、入力未送信、server assertion失敗、timeout、未対応capabilityを区別できます。