Introducing StudioTestService

Updates Announcements
,
1

Hello Creators!

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:

  1. Your plugin calls ExecutePlayModeAsync/ExecuteRunModeAsync with a test argument
  2. Scripts in the test session retrieve the argument with GetTestArgs()
  3. When testing is complete, the test calls EndTest() with the result
  4. 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!

With many thanks,
Studio Scripting Team

136 Likes
2

This topic was automatically opened after 9 minutes.

3

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.

19 Likes
4

So it’s basically an autoclicker for the playtest or run button?
I wonder how this will be used

1 Like
5

I’ve been trying to plan out how to make game tests, this is EXACTLY the solution i needed, THANK YOU

7 Likes
6

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. :+1:

15 Likes
7

This service was a good idea until I remembered that.

6 Likes
8

This looks interesting, but what would a good example for this…

2 Likes
9

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.

13 Likes
10

Loading premade testing scenarios

1 Like
11

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.

Obligatory factorio video

5 Likes
12

like elaborate on what you mean, “Loading premade testing scenarios”

13

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.

1 Like
14

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.

1 Like
15

waow.

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.

4 Likes
17

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.

This is just one example I can think of.

3 Likes
18

yea we don’t care about this cuh, just go work on UI updates like blending mode, blurr, etc

19

Cool
But I don’t really feel like celebrating Roblox updates right now

21

Passing arguments to play sessions may just be one of my favorite features ever added. Thanks!

2 Likes
22

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?

4 Likes