Agentes de IA podem executar um Playtest no Roblox Studio e verificar UI do cliente, interações e estado do servidor em um único registro.

Playtest — status e histórico de testes

Visão geral

Para a verificação normal, use uma Test Session estruturada por manage_studio. A IA executa um scenario compatível com JSON em sequência e registra target, valores esperados e observados, duração e erros de cada step. Ela não injeta código de teste como Script.

A página Playtest do Dashboard separa as áreas Test Values e Automated Test Results. Automated Test Results exibe os resultados salvos; ela não controla um teste ativo nem recalcula o resultado.

Observar e alterar valores de teste

Use a aba Test Values para registrar valores reais do Studio em perfis de teste reutilizáveis, observar os valores atuais e aplicar entradas enquanto Play ou Run estiver ativo.

Playtest Test Values — observação e alteração de valores ativos do Studio

Em Add value, escolha Studio selection para ler a seleção atual do Explorer e registrar Attributes, Value ou properties compatíveis sem adicionar código de teste. Use um Test Adapter registrado para estados internos que não podem ser selecionados diretamente.

Depois de iniciar Play ou Run, Observed values mostra valores atuais somente para leitura. Em Change values, aplique uma entrada manualmente ou de modo automático ao confirmá-la. As entradas permanecem separadas dos valores padrão salvos. Ative Apply saved defaults when Play starts para aplicar os valores salvos do perfil no início da próxima sessão Play.

Método de verificação padrão

Sem mode explícito, a session começa em Play (F5).
A v1 aceita um client e steps sequenciais.
Use Play para UI, entrada, LocalScript, PlayerGui, LocalPlayer ou comportamento do jogador.
Use Run (F8) apenas para verificações de server, world ou physics sem observação do client.
Uma session pode verificar separadamente client UI, interaction e resultado do server.

"No modo Play, verifique se a loja aparece, clique no botão de compra
com entrada real e confirme o resultado da compra no servidor."

A IA inicia a session com test_session_start e consulta progresso e step evidence com test_session_status. Use test_session_stop para cancelar uma session em execução.

Verificar UI e entrada

wait_for_gui aguarda a UI alvo.
snapshot_gui registra nomes, classes, visibilidade, posição, tamanho, ZIndex e resumo do texto.
input_click envia VirtualInput para um botão dentro do viewport.
A entrega da entrada e a observação de GuiButton.Activated ficam em evidências separadas.
Um step de server separado pode verificar a mudança final no estado do jogo.

Screenshot de pixels do viewport em Play não é compatível com a session estruturada v1. Use semantic UI snapshot e interaction evidence. manage_camera.screenshot funciona apenas em Edit.

Ler resultados no Dashboard

Test History mostra sessions estruturadas e registros Raw Luau existentes.

Campo	Descrição
Tipo de execução	`Structured` ou `Raw Luau`
Status	`passed`, `failed`, `timed_out`, `cancelled` ou `insufficient_evidence`
Mode	Play ou Run
Duration	Duração total do teste
Resumo de evidências	Quantidade de agents server/client e principal falha ou limitação

O report estruturado mostra o resultado geral, as dimensions Server, Client UI, Interaction e Visual, os valores expected/observed/evidence/error de cada step, as capabilities dos agents e os artifacts salvos.

O resultado só é passed quando todas as evidências obrigatórias passam. Um resultado correto do server com client UI ou interaction obrigatória ausente vira insufficient_evidence. Uma observação opcional com falha permanece registrada, mas não transforma verificações obrigatórias bem-sucedidas em falha.

Controle manual do Playtest

Ação	Descrição
`play_start`	Inicia Play (F5) ou Run (F8)
`play_stop`	Encerra o Playtest atual
`play_pause`	Pausa um Playtest em execução
`play_resume`	Retoma um Playtest pausado
`play_status`	Consulta o estado `edit`, `running` ou `paused` e as ações permitidas

Ações da Session estruturada

Ação	Descrição	Parâmetros principais
`test_session_start`	Valida o scenario e inicia uma session em background	`scenario`, `idempotencyKey`, seletor de Studio
`test_session_status`	Consulta o estado e uma página limitada de step evidence	`sessionId`, `stepCursor`, `stepLimit`
`test_session_stop`	Solicita cancelamento e teardown	`sessionId`

test_session_status retorna 20 steps por padrão e no máximo 50. Use o stepCursor opaco da resposta para ler a próxima página.

Diagnóstico Raw Luau

run_test continua disponível, mas não é o padrão para a verificação normal. Selecione-o explicitamente para diagnósticos avançados que exigem raw script, como uma assertion Luau específica do projeto.

run_test injeta o script em ServerScriptService.__MCP_TestRunner, coleta sinais do log e limpa o Playtest e o script temporário.

Resultados salvos

Os resultados ficam em {projectRoot}/weppy-project-sync/place_XXXXX/tests/YYYYMMDD-HHmmss/ para o Place selecionado.

test-result.json   # Resultado geral canônico e step evidence
test-report.md     # Resumo legível
test-log.txt       # Logs com origem server/client
test-context.json  # Contexto de execução e replay metadata

Registros Raw Luau existentes continuam legíveis no formato Markdown e log e não são convertidos automaticamente.

Verificação Multi-Place

Ao alterar vários Places, confirme o Studio ID e o nome de cada Place na página Connection antes de enviar pedidos direcionados. A session fixa o Studio target ao começar e não muda de Place se o Studio ativo mudar durante a execução.

Investigar uma falha

Selecione o report com falha e confira primeiro o motivo geral e o failed step. Compare expected, observed, error e a evidence dimension para distinguir UI ausente, entrada não entregue, assertion de server com falha, timeout ou capability indisponível.