Running the tests¶

Two suites, with different requirements.

JavaScript — no Unity needed¶

Covers the WebGL bridge (Plugins/WebGL/RevLearning.jslib) and the page helper that IndexInjector writes into index.html. Neither runs through a C# test: one is Emscripten glue, the other is a string constant inside an editor script. Both talk to the LMS.

cd Tests~/js
npm test

Node 18 or newer. Nothing is installed — the suites stub the handful of Emscripten globals the .jslib uses and evaluate it in a vm context, and they read the page helper straight out of IndexInjector.cs, so they always test what is actually in the repository.

Unity EditMode — needs an editor¶

RevLearning is a package, not a project, so it has to be embedded in one.

1. Create an empty project. Set ProjectSettings/ProjectVersion.txt to a Unity version the package supports (2021.3 or newer), and list these in Packages/manifest.json:

{
  "dependencies": {
    "com.unity.test-framework": "1.3.9",
    "com.unity.modules.unitywebrequest": "1.0.0",
    "com.unity.modules.jsonserialize": "1.0.0",
    "com.unity.modules.imgui": "1.0.0"
  },
  "testables": ["com.revgaming.revlearning"]
}

Test framework 1.3 or newer is required: earlier versions reject async Task test methods with "Method has non-void return value, but no result is expected". This is a test-only requirement and does not affect what the package itself supports.

Pin the test framework to the editor, not to a single version. 1.3.9 resolves on 2021.3 and 2022.3; 1.5.x is Unity 6 only, which is what the CI workflow pins because CI runs on 6000.3. The two are not in conflict — they are two editors — and picking the wrong one for your editor fails at package resolution before any test runs.

1. Put the package under Assets/, either by copying it or with a directory junction so edits are live:

mklink /J "<project>\Assets\RevGaming\RevLearning" "<path-to>\RevLearning"

1. Run headlessly. Do not pass -quit alongside -runTests; exit code 0 means everything passed.

Unity.exe -batchmode -nographics -projectPath <project> \
  -runTests -testPlatform EditMode \
  -testResults <project>/results.xml -logFile <project>/editmode.log

Running EditMode in CI¶

Both licence tiers need the account credentials and differ only in what proves entitlement:

gh secret set UNITY_LICENSE < path/to/Unity_lic.ulf
gh secret set UNITY_EMAIL
gh secret set UNITY_PASSWORD

The job fails rather than skips when they are missing, and names which one. A skipped job still reports a green tick, and "the Unity suite passed" when it never ran is worse than a red cross that tells you why.

It also asserts a floor on the test count afterwards. The failure worth guarding is a run that exits zero having executed nothing — an empty Assets/, a broken testables entry, a suite that did not compile — which otherwise looks identical to success.

Worth knowing before you set them: anyone who can push a workflow to this repository can read these secrets. A Unity account password is worth more than a CI run, so point it at a dedicated CI account if you can. Secrets are not exposed to pull requests from forks.

What the tests deliberately do not cover¶

• A real LMS. The SCORM runtimes are driven through a recording ILmsBridge, which pins the exact cmi traffic each operation produces but cannot tell you how a particular platform interprets it. Validate against the LMS your learners will actually use.
• Conformance. Nothing here substitutes for a SCORM Cloud run or the ADL Test Suite against a generated package.
• Live HTTP. The xAPI transport's request timeout is exercised by review rather than by test — that would need a server that accepts a connection and then never answers.