Los agentes de IA pueden ejecutar un Playtest en Roblox Studio y verificar la UI del cliente, las interacciones y el estado del servidor en un único registro.
Resumen
Para una verificación normal, usa una Test Session estructurada mediante manage_studio. La IA ejecuta un scenario compatible con JSON en orden y registra el target, los valores esperados y observados, la duración y los errores de cada step. No inyecta código de prueba como Script.
La página Playtest del Dashboard separa las áreas Test Values y Automated Test Results. Automated Test Results muestra los resultados guardados; no controla una prueba activa ni vuelve a calcular su resultado.
Observar y cambiar valores de prueba
Usa la pestaña Test Values para registrar valores reales de Studio en perfiles de prueba reutilizables, observar sus valores actuales y aplicar entradas mientras Play o Run está activo.
En Add value, elige Studio selection para leer la selección actual del Explorer y registrar sus Attributes, Value o properties compatibles sin añadir código de prueba. Usa un Test Adapter registrado para el estado interno que no se pueda seleccionar directamente.
Después de iniciar Play o Run, Observed values muestra valores actuales de solo lectura. En Change values, aplica una entrada manualmente o de forma automática al confirmarla. Las entradas se mantienen separadas de los valores predeterminados guardados. Activa Apply saved defaults when Play starts para aplicar los valores guardados del perfil al inicio de la siguiente sesión Play.
Método de verificación predeterminado
- Si no se indica un modo, comienza en Play (F5).
- v1 admite un client y steps secuenciales.
- Usa Play para UI, entrada,
LocalScript,PlayerGui,LocalPlayero comportamiento del jugador. - Usa Run (F8) solo para verificaciones de server, world o physics que no requieran observar al client.
- Una session puede verificar por separado la UI del client, la interaction y el resultado del server.
"En modo Play, comprueba que aparezca la tienda, pulsa el botón de compra
con una entrada real y verifica el resultado de la compra en el servidor."La IA inicia la session con test_session_start y consulta el progreso y la evidencia con test_session_status. Usa test_session_stop para cancelar una session activa.
Verificar UI y entrada
wait_for_guiespera a que la UI esté disponible.snapshot_guiregistra nombres, classes, visibilidad, posición, tamaño, ZIndex y un resumen del texto.input_clickenvía VirtualInput a un botón dentro del viewport.- La entrega de la entrada y la observación de
GuiButton.Activatedse registran como evidencias separadas. - Un step de server separado puede verificar el cambio final en el juego.
La captura de píxeles del viewport en Play no está disponible en la session estructurada v1. Usa snapshots semánticos de UI y evidencias de interaction. manage_camera.screenshot solo funciona en Edit.
Leer resultados en Dashboard
Test History muestra sessions estructuradas y registros Raw Luau existentes.
| Campo | Descripción |
|---|---|
| Tipo de ejecución | Structured o Raw Luau |
| Status | passed, failed, timed_out, cancelled o insufficient_evidence |
| Mode | Play o Run |
| Duration | Duración total de la prueba |
| Resumen de evidencia | Número de agents server/client y principal fallo o limitación |
El report estructurado muestra el resultado global, las dimensions Server, Client UI, Interaction y Visual, los datos expected/observed/evidence/error de cada step, las capabilities de los agents y los artifacts guardados.
El resultado solo es passed cuando pasa toda la evidencia requerida. Si falta UI o interaction requerida, un resultado correcto del server se registra como insufficient_evidence. El fallo de una observación opcional queda registrado, pero no convierte en fallo las comprobaciones requeridas correctas.
Control manual de Playtest
| Acción | Descripción |
|---|---|
play_start | Inicia Play (F5) o Run (F8) |
play_stop | Detiene el Playtest actual |
play_pause | Pausa un Playtest en ejecución |
play_resume | Reanuda un Playtest pausado |
play_status | Consulta el estado edit, running o paused y las acciones permitidas |
Acciones de Session estructurada
| Acción | Descripción | Parámetros principales |
|---|---|---|
test_session_start | Valida el scenario e inicia una session en background | scenario, idempotencyKey, selector de Studio |
test_session_status | Consulta el estado y una página limitada de step evidence | sessionId, stepCursor, stepLimit |
test_session_stop | Solicita la cancelación y el teardown | sessionId |
test_session_status devuelve 20 steps por defecto y un máximo de 50. Usa el stepCursor opaco de la respuesta para leer la página siguiente.
Diagnóstico Raw Luau
run_test sigue disponible, pero no es la opción predeterminada para una verificación normal. Selecciónalo explícitamente para diagnósticos avanzados que necesiten un raw script, como una assertion Luau específica del proyecto.
run_test inyecta el script en ServerScriptService.__MCP_TestRunner, recoge señales del log y limpia el Playtest y el script temporal.
Resultados guardados
Los resultados se guardan en {projectRoot}/weppy-project-sync/place_XXXXX/tests/YYYYMMDD-HHmmss/ para el Place seleccionado.
test-result.json # Resultado global canónico y step evidence
test-report.md # Resumen legible
test-log.txt # Logs con origen server/client
test-context.json # Contexto de ejecución y replay metadataLos registros Raw Luau existentes siguen disponibles en su formato Markdown y log y no se convierten automáticamente.
Verificación Multi-Place
Si modificas varios Places, confirma cada Studio ID y nombre de Place en la página Connection antes de enviar una solicitud dirigida. La session fija el Studio target al comenzar y no cambia de Place aunque cambie el Studio activo durante la ejecución.
Investigar un fallo
Selecciona el report fallido y revisa primero el motivo global y el failed step. Compara expected, observed, error y la evidence dimension para distinguir entre UI ausente, entrada no entregada, assertion de server fallida, timeout o capability no disponible.