We’re excited to announce the release of StudioTestService, a new Studio service that allows plugins to automate and customize Studio’s play test features. With StudioTestService, your plugins can launch tests that jump straight to a specific part of your game, or run complex code tests automatically.
How to Use StudioTestService
StudioTestService exposes four methods:
1. StudioTestService:ExecutePlayModeAsync(value): result 2. StudioTestService:ExecuteRunModeAsync(value): result
Starts a test session in Play Solo or Run mode (respectively)
The argument passed can be retrieved with GetTestArgs()
Waits until EndTest() is called from within the test session and returns the result that was passed to it
3. StudioTestService:GetTestArgs()
Returns the argument passed to ExecutePlayModeAsync or ExecuteRunModeAsync
4. StudioTestService:EndTest(result)
Terminates the current test session
Passes result back to the calling ExecuteAsync method
You can browse the full documentation for the service here.
How It Works
StudioTestService enables communication between your plugin and test sessions:
Your plugin calls ExecutePlayModeAsync/ExecuteRunModeAsync with a test argument
Scripts in the test session retrieve the argument with GetTestArgs()
When testing is complete, the test calls EndTest() with the result
Your plugin receives this result and continues execution
Plugin Script
local StudioTestService = game:GetService("StudioTestService")
local levelToTest = 2
local testResult = StudioTestService:ExecuteRunModeAsync(levelToTest)
Server Script
local StudioTestService = game:GetService("StudioTestService")
local RunService = game:GetService("RunService")
if not RunService:IsStudio() or not RunService:IsRunMode() then
return
end
local testLevel = StudioTestService:GetTestArgs()
if testLevel then
startLevel(testLevel)
else
startLevel(1)
end
We’re excited to see what you do with this new service! Please drop any feedback, suggestions, or questions below!
The args are awesome, since this means you can make a plugin that stores testing locations and then click a button in a widget to test at a stored location. Like Test Here, but for cached locations.
I’m open to making that plugin if there’s interest for it, although I’m sure this update will cause a plethora of identical plugins.
Nice. This wasn’t my biggest concern (personally I cared more about game development on Roblox being attacked by your attempts to age check creativity) but I think that the few people who do age check will like this.
Are pre-push/pre-commit git-like hooks planned for Roblox? Would be useful for built-in unit testing without Luau Execution.
E.g. a script that automatically runs when you attempt to publish a place, if said script fails, publish is canceled.
Could we get a solution that allows us to execute tests in bulk with headless clients and servers? This would actually allow us to do automatic testing for certain things. (assuming im not misunderstanding how this works, my understanding is it just starts the play session for you)
Most of what this provides was practically possible already with plugin settings and using BindableEvents (or instances in general) to send the data in at runtime, which is disappointing because we’re not breaking much new ground here other than being a slightly easier API.
E.g. a combat game, a test scenario could look like spawning NPCs at specific positions on a map.
Really just anything that reduces time between you pressing play and actually testing what you want to test.
This is a good QoL change for developers (& particularly bigger studios) that have their own plugin tools for time-saving on testing specific scenarios! Would be great to immediately load into (for example) a tutorial environment, rather than load up the game and go through menus to access the tutorial. Or for forcing special game modes & changing parameters to load into the test with.
Thanks for fixing that old broken RunService method and making it 10x better.
I think the next step would be allowing us to use those plugin communication methods that were locked for some reason, there’s several usecases for sending data between the Server/Client plugin environment and the Edit plugin.
Main point is automation, basically auto-clicker as you said.
I’ve been recently working on vehicles with a-chassis. A-chassis system is quite customizable, with over 100 line tuning config. I have to run and test multiple times and adjust the tuning file, so that the cars springs bounce correctly, engine has correct settings, etc.
I would see there being possibility to combine AI via MCP server and this new feature, to create a plugin to fine tune the a-chassis, for example, to ease the hassle and save some of my time.
These look like some really interesting APIs, but could we potentially get a conclusive list of all the APIs that exist for plugins on the documentation? Currently, all the APIs for plugins are spread across multiple different services and APIs such as Plugin, Selection, ScriptEditorService, StudioService, and more. While splitting these up based on their use cases does make sense, and it definitely helps to keep things organised, it also makes it a nightmare for people trying to get into plugin development to figure out what they can even do and interact with (I’d never even heard of ScriptEditorService until a few months ago, and that has some incredibly powerful APIs). Could we potentially see a “See Also” section added somewhere which lists these additional pages, maybe at the top of the Plugin documentation, or at the very end of the Studio Plugins tutorial?
