How this site checks its own code
Tutorial code that was never run is a guess with syntax highlighting. The scripts published here are extracted from the article you read and handed to a real Godot 4.7.2 process. This page shows exactly what that process did, and what it did not do.
The harness reads the article, not a copy of it
The usual failure mode for a tutorial site is that the code in the article and the code the author tested drift apart: the article is edited, the test project is not, and a reader hits an error the author never sees. This harness removes that gap by reading the published article body and hashing each code block it extracts, so a test result always belongs to an exact version of the text on the page.
- Extract. Each code block is pulled from the article's own content and recorded with a SHA-256 hash of the exact text a reader sees.
- Assemble. The scripts are written into a throwaway Godot project with a minimal scene fixture, following the assembly steps the article itself describes.
- Import and compile. Godot imports the project and runs
--check-onlyagainst every complete script. - Run and assert. A headless run drives the scene and asserts specific outcomes. The run fails on any script error, parse error, or failed assertion.
- Publish. The results regenerate the badge data the articles render, so a page can never claim a stronger check than the engine performed.
Last run against Godot 4.7.2.stable.steam.ed1daf0bf on . The complete machine
output, including every file hash and every exclusion reason, is committed to the
repository at docs/verification/godot-runtime-evidence.json.
Executed and asserted
The scripts in these 9 articles ran in a real engine and passed behavioral assertions.
Compiled, not executed
Godot accepted the complete scripts in these 15 articles: names and signatures resolve against the engine API. They were not run, so their behavior is not established.
What this does not prove
- A headless run has no renderer. Nothing here verifies that a scene looks right — lighting, layout, and visual polish are checked by eye, and articles say so where it matters.
- Assertions cover the behavior named in each article's review note, not every example on the page. A tested badge is not a claim that the whole tutorial was played through.
- C# examples are checked against the Godot .NET API reference. The harness compiles GDScript only.
- 36 code blocks are excluded by design, each with a recorded reason. Fragments and intentionally wrong examples are inventoried, not padded into fake programs to inflate a number.
Common questions
What does the 'Code tested in Godot' badge mean?
The scripts printed in that article were extracted from the published page, written into an empty Godot project, and run by a real headless Godot 4.7.2 process. The run asserts specific behavior — that a character lands, that a save file round-trips, that a depleted health bar stops processing. If an assertion fails, the build fails.
What does 'Code compiled in Godot' mean, and why is it weaker?
Godot loaded the script and accepted it: the syntax parses, the class names resolve, and the method signatures match the engine's API. It does not mean the code was run, so it cannot tell you the logic is correct. It is a real check, but a narrower one, and the badge says so.
Why are some code blocks never checked?
36 published blocks are excluded on purpose. Some are deliberately wrong (a Godot 3 example shown so you can recognise it), some are not GDScript, and some are fragments that need surrounding code the reader supplies. Each exclusion is recorded with a reason in the evidence file rather than quietly dropped.
Can I reproduce this myself?
Yes, and that is the point. Clone the repository, set GODOT_BIN to your own Godot binary, and run npm run test:godot. The harness reads the article content directly, so it verifies what you are reading, not a separate copy that can drift from it.