Testing RevFramework¶

RevFramework is built test-first. The suite is large — there is more test code in the project than there is code under Runtime/ — and every system is covered by adversarial ("does it break under hostile input?") and internal-truth ("does it do what it claims?") tests.

Those tests are not in this package, by design. This is not an omission — it is the same principle as everything else here: show everything, hide nothing, but don't put things in your project that you didn't ask for.

Why the tests ship separately¶

A game project should not carry a framework's test suite unless its author wants it. Bundling ~45,000 lines of tests into every install would:

• roughly double the package size,
• drop dozens of framework test assemblies into your Test Runner, mixed in with your own tests,
• and pull in test-only dependencies you have no reason to compile.

You do not need any of it to use RevFramework. Only the Runtime/ folder is required to build your game.

So the tests live where they belong: a free, opt-in download for the developers who actually want to run them.

What the suite covers¶

Offered so you can see exactly what "well tested" means here — not marketing:

• EditMode — Hostile. Deliberately abusive input: throwing listeners, missing dependencies, out-of-order calls, boundary values. These exist to break the framework before your game does.
• EditMode — InternalTruth. Pins documented behaviour against the code — the <returns> / <remarks> contract each public method actually honours.
• PlayMode. Behaviour that needs a running player loop: real time passing, lifecycle, and the Teachable Panels.
• Convention tests. Structural guards that stop a fixed bug class from silently returning (e.g. every designer event must be raised through a guarded path).

They run on every change¶

Not only when someone remembers. Continuous integration builds a clean Unity project around the framework and runs both suites on every push:

Both green. The counts are stated rather than summarised because a number you can check is worth more than an adjective — and because the same suites produce exactly these figures when run locally, which is the only way to know CI is testing the whole framework rather than the part that happened to compile.

That last point is the one that earns its keep. Test assemblies here are gated by scripting defines, and a missing define does not fail an assembly — it removes it, leaving a run that passes having quietly tested less. So each mode carries a minimum test count that turns a shrunken run red, and the results file is read directly rather than trusting the exit code. Both guards have already caught real faults, including one where Unity exited successfully, reported "Passed", and had run nothing at all.

Getting the tests¶

The test package is free, but limited to owners — the tests do nothing without the framework itself, so there is no point downloading them otherwise. Enter the invoice number from your Asset Store purchase and the download will start.

Your invoice number is in the Unity Asset Store purchase confirmation email (inside the PDF attachment), or in your Unity account under order history.

Then:

1. Update the framework first if you are behind. The download is always the current release — there is one package and earlier versions are not served. The suites are pinned to the behaviour of the release they shipped with, so running them against an older framework reports failures that are version drift rather than real bugs. Check what you are on with RevFrameworkVersion.Current, or the version at the bottom of the Welcome window.
2. Import it. Only the tests for the systems you actually own will compile; the rest gate themselves out automatically.
3. Restore anything you removed first. That gating handles a system being absent. It cannot handle one being only partly there. If you have deleted systems and run Cleanup Orphaned Content…, import the tests only once everything you intend to keep is fully restored from _RevFrameworkTrash — which sits beside your Assets folder, not inside it, one subfolder per cleanup session.

The fingerprint is a CS0234 naming a sub-namespace while its parent resolves fine — The type or namespace name 'Teaching' does not exist in the namespace 'RevGaming.RevFramework.Health' means Health is back but its teaching panels are still in the trash. Integration namespaces fail the same way. These errors look like the test package is broken; it is not. The project is incomplete, and restoring the rest clears them.

Full run instructions, and the things worth knowing before you hit "Run All", ship inside the package.

Who this is for¶

If you are extending RevFramework, subclassing its components, or want a regression net around modifications you make, the test download is for you. If you are simply using the framework as shipped, you never need it — the framework is already tested; the download lets you prove it in your own project, and doubles as a set of worked examples for testing your own systems against it.