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.

Useful switches:

Switch	Effect
-Only Tools,Samples	run a subset (Tools, Samples, CppProjects, Mcp)
-IncludeRemote	also download, transform and run Bistro / Monster Attack / Store (slow, several GB)
-AllScenes	run every scene of every project, not just the main scene
-Renderer DX11	only one renderer instead of DX11 and Vulkan
-SkipExport	skip the project export and the run of the exported project
-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.