Release Test Checklist

What to run before publishing a release package. Everything here is done on a normal PC with the downloaded package - the point is to test what a user actually gets.

1. Get the package

• Download the artifact of the build-release-package workflow run.
• Extract it to a path that is not the build path and contains a space, e.g. D:\ez test\ezEngine.Release.X.Y.Z. A surprising number of package-only bugs are path bugs.

2. Run the automated suite

Utilities\Scripts\ReleaseTest\Run-ReleaseTests.ps1 `
  -SdkDir "D:\ez test\ezEngine.Release.X.Y.Z" `
  -OutputDir "D:\ez-test\results-X.Y.Z"

Takes roughly 15-30 minutes. Exit code is the number of failed checks, and Summary.md in the output folder lists every check.

Each switch below adds that group to the run. Give none of them and everything runs, without exception (including the slow remote-project checkout and standalone samples). Give any of them and only the given groups run.

Switch	Effect
-Tools	the Tools group
-Cpp	the CppProjects group
-Mcp	the Mcp group
-EditorSamplesLocal	local sample projects' main scene, through ezPlayer
-EditorSamplesRemote	download, transform and run Bistro / Monster Attack / Store (slow, several GB)
-EditorSamplesAllScenes	modifier: run every scene instead of just the main scene, for whichever of -EditorSamplesLocal / -EditorSamplesRemote is also given; enables neither by itself
-StandaloneSamples	the standalone sample executables (TextureSample, ShaderExplorer, ...)
-Renderer DX11	only one renderer instead of DX11 and Vulkan (DX11, Vulkan, or All)
-SkipExport	skip the project export and the run of the exported project, within CppProjects
-BinDir <path>	test a build workspace instead of a package

What the groups cover:

• Tools - every shipped executable starts; the console tools answer -help without crashing.

• Samples - every sample starts through ezPlayer, renders, exits cleanly, logs no errors, and produces a non-black screenshot, on DX11 and Vulkan.

• CppProjects - the C++ plugin of PacMan / RTS / Asteroids and of a freshly created project builds against the package; the generated CMake points at the extracted package and not at the build machine; the project export runs and the exported game starts.

• Mcp - the editor's MCP server comes up on a project, the tool inventory is complete, a scene can be opened and inspected, play-in-editor works, a screenshot of the running game is captured, and app_quit leaves no processes behind. Same for ezPlayer -mcpport.

• Suite exits with 0. Investigate every FAIL; a SKIP is only acceptable if the reason in Summary.md is.

3. Manual pass

The automated suite deliberately does not cover interactive behaviour. Walk these by hand:

• Editor.bat - the dashboard opens, the sample list and its thumbnails are shown.
• Download one remote sample (Bistro or Monster Attack) through the dashboard; it clones, unpacks, transforms and opens.
• New-project wizard: create a "Basic FPS" project, open it, play it.
• Open Testing Chambers: browse assets, drag & drop a mesh into the scene, move it with the gizmo, change a property, undo and redo, save, play-in-editor.
• Create a few documents by hand (material, particle effect, prefab) and check that their editors open.
• Open the generated C++ solution in Visual Studio, build it, and reload the plugin in the editor.
• The four standalone sample applications start, render and can be closed: TextureSample.exe, MeshRenderSample.exe, ShaderExplorer.exe, ComputeShaderHistogram.exe. (They are plain ezApplications, so they have none of the unattended options and cannot be scripted.)
• ezInspector.exe against a running ezPlayer - it connects and shows live data.
• One MCP session from a real client: claude mcp add --transport http ez-editor http://127.0.0.1:7399/mcp after starting ezEditor.exe -project "Data/Samples/Testing Chambers" -unattended -editor-mcpport 7399.
• High-DPI or second monitor: the window layout survives an editor restart.
• Follow Readme - Getting Started.md and confirm the steps still match what the package does.