aowlspt/fixture

Source: aowl/src/aowlspt/fixture.nim — 124 lines.

Where an offline binding self-test is allowed to get a runtime from.

Several mods carry a --side sim self-test that reports, offline, which of their IL2CPP bindings resolve and which refuse. With no runtime in the process every one of them refuses for that reason, which is a true answer but a thin one, so the self-tests can be pointed at a GameAssembly.dll to load: tests/mockil2cpp builds a stand-in implementing the same C API, and the gate points them at it.

Pointing them at one is a LoadLibrary of a second GameAssembly.dll, and that is why this module exists rather than each mod reading the key itself. Until now the path came from selfTestRuntime in the mod's config.json, it was a repository-relative path -- tests/mockil2cpp/GameAssembly.dll -- and aowl payload copies each mod's config.json into the installer payload verbatim. So a development fixture path shipped into a player's install. It fired on nothing, for two reasons that are both accidents rather than rules: the self-test only runs on sideSim and no simulator ships in a payload, and the relative path resolves to nothing outside a checkout. A thing that is safe only because it never happened is not safe.

Two rules, and between them the fixture cannot steer a real client however a config.json reaches it:

1. A path must be absolute. A relative one resolves against whatever directory the host happened to be started in, which in an install is the game's own directory -- that is a LoadLibrary of a file chosen by the working directory, and it is refused with the reason said out loud. It is also the only form the loader defines here: openIl2Cpp loads with LOAD_WITH_ALTERED_SEARCH_PATH so that GameAssembly.dll finds UnityPlayer.dll beside itself, and that flag's behaviour is only specified for an absolute path.

2. The value can come from the environment, AOWLSPT_SELFTEST_RUNTIME and AOWLSPT_SELFTEST_DATADIR, which is where the gate now puts it. That is what lets the committed config.json keys be empty: the fixture path is set by the harness that owns the fixture, for the child processes it starts, and there is nothing left in a mod's config for aowl payload to carry into an install. The key stays declared, and empty, because it is a real thing a developer can set to a real client's GameAssembly.dll -- with an absolute path, which is the only kind that would have worked.

The refusal is a warning and a fallback, never a failure: the self-test then reports against the process, which is the same answer it gave before anyone thought to point it at a runtime.

Types

SelfTestPath

  SelfTestPath* = object
    path*: string
    source*: string
    refusal*: string

What the self-test should do about a runtime or a data directory.

aowl/src/aowlspt/fixture.nim:55

Constants

EnvRuntime

  EnvRuntime* = "AOWLSPT_SELFTEST_RUNTIME"

Set by aowl for the simulator runs in the gate and by aowl run.

aowl/src/aowlspt/fixture.nim:49

EnvDataDir

  EnvDataDir* = "AOWLSPT_SELFTEST_DATADIR"

The *_Data directory il2cpp_init is given, when there is one.

aowl/src/aowlspt/fixture.nim:51

Routines

isAbsolutePath

proc isAbsolutePath*(p: string): bool

Windows, and deliberately strict. C:\x and \\host\share\x are absolute; \x and /x are drive-relative -- they mean "the current drive", which is as much a function of where the host was started as tests\x is -- and are not accepted.

aowl/src/aowlspt/fixture.nim:84

selfTestRuntime

proc selfTestRuntime*(configured: string): SelfTestPath

The GameAssembly.dll an offline binding report should be run against.

aowl/src/aowlspt/fixture.nim:115

selfTestDataDir

proc selfTestDataDir*(configured: string): SelfTestPath

The *_Data directory handed to il2cpp_init when a runtime was loaded out of process. Same rule, for the same reason: it is a path a development fixture supplies, and an install has no business acting on a relative one.

aowl/src/aowlspt/fixture.nim:119