QORPOAI-assisted game tests: decide the expected result first
Before accepting an AI-drafted game test, decide what the correct result should be and write it down separately from the generated test. Start with a known game state, perform one meaningful action, and assert the outcome that a player or another system depends on. An automated test is most useful when it can catch the wrong behaviour even if that behaviour already exists in the code.
Start with a rule you can explain in a sentence
Ask a designer or the owner of the feature to describe the smallest promise the test should cover. For an inventory action, that might be that a failed pickup leaves both the world item and the player's inventory available in the same state. The test has two things to check after the action. The pickup should fail in the defined case, and the item should still exist where the player can attempt it later.
If the game has several pickup systems, choose one and name it. An ordinary loose item can follow different rules from a quest reward, a transfer between bags or an item sent to a fallback mailbox. A test that tries all of those paths at once makes it harder to tell which promise failed.
Give the model a fixture and a separate answer
A fixture is the small set of data and objects the test needs to start. The example here uses a fictional two-slot inventory. Each slot holds one item and there is no stacking. Both slots begin occupied. A third item is placed on the ground and the action is to attempt an ordinary pickup. The expected result is a full-inventory response, two unchanged slots and a world item that remains available.
Now make a second case with the second slot free. Everything else stays the same. The expected result is a successful pickup, the third item in the previously free slot and the corresponding world item removed. The two cases differ in one input. If both pass, you have a better signal that the test is observing the capacity boundary rather than a generic failure or success response.
Keep the expected values visible in the test. If the test uses the same production helper to calculate both the game result and the expected result, a single broken assumption can make both agree. A concrete expected slot index or a simple literal count makes the reasoning easier for a reviewer to follow.
Model example: find a test that passes for the wrong reason
Suppose a generated test performs the failed pickup and checks that the bag contains two items. It passes. During manual review, someone notices that a successful code path can replace the second item and still leave the count at two. The count was accurate and the test missed the loss.
Add an assertion for the identities of both starting items. Check that the item on the ground remains available. Then deliberately change the fixture so the capacity check should succeed. The original assertion is still useful, but it now sits beside the details that distinguish the intended outcome from a superficially similar one.
Make each run independent
Set up the bag, world item and player within the test. Avoid reading a profile that another test can change. Reset what the test creates and use an isolated copy of any file it needs to write. If a test only passes after another test has equipped the right item, the order has become an unrecorded part of the fixture.
Epic's Automation Test Framework guidelines describe why test state and disk cleanup matter when cases run in different orders or on different machines. The principle applies to AI-drafted tests as well. Review setup and cleanup before relying on a generated suite.
What should the reviewer check before merging?
Read the fixture, action and assertions in that order. Verify that each assertion would fail for at least one realistic bug. Run the test through the normal project runner, then check one intentional failure in the test environment to make sure the result is observable. Use the actual run output when recording a pass.
For adjacent review work, see our review checklist for AI-generated game code, review of stale UI responses and test for the first action after resuming a game. Each starts from a concrete behaviour the player can observe. Follow QORPO Studio Live for more development notes.