Les agents IA peuvent lancer un Playtest dans Roblox Studio et vérifier l’UI client, les interactions et l’état serveur dans un même enregistrement.

Playtest — état et historique des tests

Vue d’ensemble

Pour une vérification courante, utilisez une Test Session structurée via manage_studio. L’IA exécute un scenario compatible JSON dans l’ordre et enregistre le target, les valeurs attendues et observées, la durée et les erreurs de chaque step. Elle n’injecte pas de code de test sous forme de Script.

La page Playtest du Dashboard sépare les espaces Test Values et Automated Test Results. Automated Test Results affiche les résultats enregistrés ; cet espace ne contrôle pas un test actif et ne recalcule pas son résultat.

Observer et modifier les valeurs de test

Utilisez l’onglet Test Values pour enregistrer des valeurs Studio réelles dans des profils de test réutilisables, observer leurs valeurs actuelles et appliquer des entrées pendant que Play ou Run est actif.

Playtest Test Values — observation et modification des valeurs Studio actives

Dans Add value, choisissez Studio selection pour lire la sélection actuelle de l’Explorer et enregistrer ses Attributes, sa Value ou ses properties prises en charge sans ajouter de code de test. Utilisez un Test Adapter enregistré pour un état interne qui ne peut pas être sélectionné directement.

Après le démarrage de Play ou Run, Observed values affiche les valeurs actuelles en lecture seule. Dans Change values, appliquez une entrée manuellement ou automatiquement lors de sa validation. Les entrées restent distinctes des valeurs par défaut enregistrées. Activez Apply saved defaults when Play starts pour appliquer les valeurs enregistrées du profil au démarrage de la prochaine session Play.

Méthode de vérification par défaut

Sans mode explicite, la session démarre en Play (F5).
La v1 prend en charge un client et des steps séquentiels.
Utilisez Play pour l’UI, les entrées, LocalScript, PlayerGui, LocalPlayer ou le comportement du joueur.
Utilisez Run (F8) uniquement pour les vérifications server, world ou physics sans observation client.
Une session peut vérifier séparément client UI, interaction et résultat server.

"En mode Play, vérifie que la boutique s’affiche, clique sur le bouton d’achat
avec une entrée réelle, puis vérifie le résultat de l’achat sur le serveur."

L’IA démarre la session avec test_session_start et lit la progression et les step evidence avec test_session_status. Utilisez test_session_stop pour annuler une session active.

Vérifier l’UI et les entrées

wait_for_gui attend que l’UI cible soit disponible.
snapshot_gui enregistre les noms, classes, visibilité, position, taille, ZIndex et résumés de texte.
input_click envoie VirtualInput à un bouton situé dans le viewport.
L’envoi de l’entrée et l’observation de GuiButton.Activated sont enregistrés séparément.
Un step server séparé peut vérifier la modification finale de l’état du jeu.

Les screenshots pixel du viewport en mode Play ne sont pas pris en charge par la session structurée v1. Utilisez les semantic UI snapshots et interaction evidence. manage_camera.screenshot fonctionne uniquement en mode Edit.

Lire les résultats dans le Dashboard

Test History affiche les sessions structurées et les enregistrements Raw Luau existants.

Champ	Description
Type d’exécution	`Structured` ou `Raw Luau`
Status	`passed`, `failed`, `timed_out`, `cancelled` ou `insufficient_evidence`
Mode	Play ou Run
Duration	Durée totale du test
Résumé des preuves	Nombre d’agents server/client et échec ou limite principale

Le report structuré présente le résultat global, les dimensions Server, Client UI, Interaction et Visual, les données expected/observed/evidence/error de chaque step, les capabilities des agents et les artifacts enregistrés.

Le résultat n’est passed que si toutes les preuves requises réussissent. Un résultat server réussi sans client UI ou interaction requise devient insufficient_evidence. L’échec d’une observation facultative reste enregistré, mais ne transforme pas les vérifications requises réussies en échec.

Contrôle manuel du Playtest

Action	Description
`play_start`	Démarre Play (F5) ou Run (F8)
`play_stop`	Arrête le Playtest actuel
`play_pause`	Met en pause un Playtest en cours
`play_resume`	Reprend un Playtest en pause
`play_status`	Lit l’état `edit`, `running` ou `paused` et les actions autorisées

Actions de Session structurée

Action	Description	Paramètres principaux
`test_session_start`	Valide le scenario et lance une session en background	`scenario`, `idempotencyKey`, sélecteur Studio
`test_session_status`	Lit l’état et une page limitée de step evidence	`sessionId`, `stepCursor`, `stepLimit`
`test_session_stop`	Demande l’annulation et le teardown	`sessionId`

test_session_status renvoie 20 steps par défaut et 50 au maximum. Utilisez le stepCursor opaque de la réponse pour lire la page suivante.

Diagnostic Raw Luau

run_test reste disponible, mais ce n’est pas le choix par défaut pour une vérification courante. Sélectionnez-le explicitement pour un diagnostic avancé nécessitant un raw script, comme une assertion Luau propre au projet.

run_test injecte le script dans ServerScriptService.__MCP_TestRunner, collecte les log signals, puis nettoie le Playtest et le script temporaire.

Résultats enregistrés

Les résultats sont stockés sous {projectRoot}/weppy-project-sync/place_XXXXX/tests/YYYYMMDD-HHmmss/ pour le Place sélectionné.

test-result.json   # Résultat global canonique et step evidence
test-report.md     # Résumé lisible
test-log.txt       # Logs avec origin server/client
test-context.json  # Contexte d’exécution et replay metadata

Les enregistrements Raw Luau existants restent lisibles au format Markdown et log et ne sont pas convertis automatiquement.

Vérification Multi-Place

Pour plusieurs Places, confirmez d’abord chaque Studio ID et nom de Place sur la page Connection. La session fixe le Studio target au démarrage et ne change pas de Place si le Studio actif change pendant l’exécution.

Analyser un échec

Sélectionnez le report en échec et examinez d’abord la raison globale et le failed step. Comparez expected, observed, error et evidence dimension pour distinguer une UI absente, une entrée non transmise, une assertion server en échec, un timeout ou une capability indisponible.