# Testing Patterns

**Analysis Date:** 2026-05-01

## TL;DR

**There is no automated testing in this repository, and there never was.** This is an archival/preservation repository for a single-developer game project (2008–2017) plus reverse-engineering documentation produced in 2026. No test framework is configured, no test directories exist, no CI pipelines are present, and no test files of any kind are committed.

If you arrived here looking for `npm test`, `pytest`, `dotnet test`, or anything analogous: **none of those will work** — there is no project manifest to even invoke them against.

## Evidence: What Was Searched

The following globs were run across the entire tree and returned **no results**:

| Glob | Result |
|---|---|
| `**/*_test.*` | No test files. (Two false-positive matches: `tile_Blue_test.png` and `tile_Blue_test.mat` — Unity texture/material assets named "test", not test code.) |
| `**/*.test.*` | No matches. |
| `**/test*/**` | No matches. |
| `**/.github/workflows/*` | No matches. |
| `**/.github/**` | No matches. |
| `**/.gitlab-ci.*` | No matches. |
| `**/azure-pipelines*` | No matches. |
| `**/Dockerfile*` | No matches. |
| `**/Makefile` | No matches. |
| `**/*.yml` | No matches. |
| `**/*.yaml` | No matches. |
| `**/pyproject.toml` | No matches. |
| `**/package.json` | No matches. (The `.mirror.js` / `.mirror-fix.js` provenance scripts in `legacy/` run via raw Node and have no manifest.) |
| `**/*.eslintrc*` / `**/.prettierrc*` / `**/.editorconfig` | No matches. |

## Per-Subsystem Testing Posture

### GameMaker 5.3a game (`legacy/source-archive/`, `legacy/open-source-release/`, `legacy/servers/`)

**Test framework:** None. Game Maker 5.3a has no built-in unit test concept — there are no headless CLI hooks (per `decomp/wiki/01-runner-architecture.md` and `decomp/GameMaker 5.3a Reverse Engineering Pipeline.md` introduction). The IDE is GUI-only; "testing" in this era meant pressing F5 (Run) inside the IDE.

**Manual QA artifacts found:**
- **Debug builds:** `legacy/source-archive/BNO/BNO_Server/BN Online Master 5-2 DEBUG.exe` / `.gmd` / `.gb1` — a labeled debug variant of the 5-2 server, the only build with `DEBUG` in its filename (per `legacy/README.md:64`).
- **Server watchdog pair:** `Server Saver.exe` and `Crasher (Test With Server Saver).exe` (in `legacy/open-source-release/` and `legacy/servers/local-current/`) — explicitly named per `legacy/README.md:81`: "server watchdog + accompanying test crasher". This is **the only test artifact in the whole repo**: a manual smoke-test where you launch the crasher to verify the saver detects the crash and restarts the master.
- **Operator-console probes:** `,ServerCommands.txt` documents in-runtime debug keybinds: `Ctrl+Q` ("inspect chat-bar var"), `Ctrl+E` ("exec clipboard code"), `Ctrl+9` (player context menu), `Ctrl+M` (view message boards). These are admin/inspection hooks, not tests, but functioned as the live-debugging interface (per `legacy/README.md:78-80`).
- **Logs:** `DebugLog.txt`, `MB_Log.bnb`, `server_log.txt` are present in every server snapshot — runtime logging output, not test output.

**Coverage:** Zero automated; manual playtesting only. Per `legacy/README.md:108-112`, no formal protocol spec exists beyond `BN Online Message ID's Table.xls` and inline `.gml` comments — all behavior was specified by what shipped.

### Unity port (`legacy/unity-project/`)

**Test framework:** None. Unity 5.3.4f1 (per `legacy/unity-project/ProjectSettings/ProjectVersion.txt`) shipped a Unity Test Runner, but it is **not configured here** — there is no `Assets/Tests/` directory, no `Assets/Editor/Tests/` directory, no `*.asmdef` files, no `EditorTests` folder, no `PlayModeTests` folder.

**False-positive note:** `legacy/unity-project/Assets/_Textures/tile_Blue_test.png` and `legacy/unity-project/Assets/_Materials/tile_Blue_test.mat` are art assets — a blue tile prototype called "test", not a test fixture.

**Code-level "test" residue:**
- `legacy/unity-project/Assets/_Scripts/SideTextureRotationTest.cs` — a `MonoBehaviour` named "Test" but it is a runtime script, not a unit test (no test runner attribute, no assertions).
- `legacy/unity-project/Assets/_Shaders/HeightTest.shader` and `testShader.shader` — exploratory shaders, again not tests.

**Build artifacts as proxy QA:** `legacy/unity-project/Test Builds/` contains `Android/` and `Windows/` subdirectories (per the directory listing) holding prebuilt APKs and a standalone `.exe` (~22 MB Android, 16 MB Windows, plus 138 MB of `.pdb` debug symbols per `legacy/README.md:101`). The directory name "Test Builds" implies these are dev/internal builds for manual QA, not release candidates.

**csproj sync conflicts:** ~10 `Assembly-CSharp* (BNO Successor's conflicted copy YYYY-MM-DD).csproj` files in `legacy/unity-project/` reflect Dropbox sync wars — not test fixtures.

**Coverage:** Zero. The port was abandoned 2017-05 (per `legacy/README.md:97`) before any test scaffolding was added.

### Maya pipeline (`legacy/maya-project/`)

**Test framework:** N/A. This is an art/asset directory (`workspace.mel`, `scenes/`, `images/`, `sourceimages/`) — testing is not a meaningful concept here.

### Reverse-engineering documentation (`decomp/`)

**Test framework:** N/A. The contents of `decomp/wiki/` are markdown research notes about decompiling the legacy game; no executable code lives in this subtree to test.

**Validation discipline noted in docs:** `decomp/wiki/15-extraction-pipeline.md` is described as a "ranked methodology (4 tiers)" for `.gmd` extraction — i.e., a manual test/verification matrix for which extraction tools work against which `.exe` variants. This is a **methodology**, not a test suite, but it is the closest thing to systematic QA the repo contains.

### Provenance scripts (`legacy/.mirror.js`, `legacy/.mirror-fix.js`, `legacy/.mirror-report.json`)

**Test framework:** None. Per `legacy/README.md:115-117`, these are one-shot Node mirroring scripts run on 2026-05-01 to populate the archive. They ran once and produced `.mirror-report.json` (a fetch result log: 778 MB / 7958 files / 0 fetch failures per `legacy/README.md:5`) — that JSON serves as the implicit "test result" for the archive's completeness.

## CI / Continuous Integration

**None.** No `.github/workflows/`, no GitLab CI, no Azure Pipelines, no Jenkins, no CircleCI, no Travis, no AppVeyor configs. The repository itself is not even initialized as a git repo (per the run prompt: "Is directory a git repo: No"), so there is no commit/push event for any CI to attach to.

## Coverage Summary

| Subsystem | Automated tests | Manual QA evidence | CI |
|---|---|---|---|
| GML game (client + server) | None | Server-Saver/Crasher pair; in-game debug keybinds; `DEBUG` build variant of Master 5-2; runtime logs | None |
| Unity port | None | "Test Builds/" output directory only | None |
| Shaders | None | `HeightTest.shader`, `testShader.shader` (exploratory, not test) | None |
| Maya assets | N/A | N/A | N/A |
| Decomp documentation | N/A | Tier-ranked extraction methodology in `decomp/wiki/15-extraction-pipeline.md` | N/A |
| Mirror scripts | None | `.mirror-report.json` fetch result log (one-shot) | None |

## Implications for Future Work

If the goal of any future phase under this repo is to produce **new, working code** (e.g., a modern reimplementation, a `.gmd` parser, a protocol bridge), there is **no testing baseline to inherit and no convention to match**. Any test infrastructure introduced will be greenfield, and conventions for it must be chosen explicitly rather than inferred from the existing tree.

If the goal is purely **archival** (continuing to preserve and document what exists), no testing is required — manual verification (does the binary still launch under DOSBox/Wine/native? does the documented extraction pipeline still produce the documented `.gmd`?) remains the appropriate QA stance.

If the goal is **decompilation/extraction** of `.gmd` payloads from `.exe` runners, the closest thing to a "test suite" is the version matrix in `legacy/README.md:53-67` (ten Master builds + ten Client builds, dated 2008–2014) — running each candidate extractor against each known-good binary and verifying the recovered GML compiles and runs is a viable correctness test, but no harness exists; it would have to be built.

---

*Testing analysis: 2026-05-01*