Convert Warcraft III tests to .j and reduce test harness

[corepunch]

Summary

Migrate Warcraft III gameplay tests from the C harness to .j fixtures wherever the JASS surface is a better fit. The goal is to make tests easier to follow, closer to production scripting, and smaller in the long term.

Why this change exists

• Tests written in .j mirror the real Warcraft III scripting entrypoint more closely than direct C harness calls.
• The current harness is carrying a lot of game-state scaffolding that is only there to support gameplay assertions.
• Once dedicated server mode exists, these tests can run against the real game module instead of mocked C-side state.

Dependency

This issue is blocked by #116 (Add dedicated server mode (headless, no client)). We need a headless runtime before .j gameplay tests can run cleanly against the real game module.

What currently exists

• There is no hero_inventory_test.j or similar gameplay fixture yet.
• The closest existing .j file is test_jass_assertions.j, which tests JASS assertion natives rather than gameplay behavior.
• Gameplay coverage currently lives in C through test_harness.c / test_harness.h.

The harness currently owns:

• Global game state that normally belongs in g_main.c (gi, globals, game, level, g_edicts)
• Mock gi function pointers for allocation, entity linking, edict queries, and similar plumbing
• Hardcoded unit metadata for test actors such as hpea, hfoo, hbar, and Hpal
• Raw edict allocation helpers that bypass normal spawn/model setup
• Stubs for game symbols that are not linked into the test binary

Suggested migration order

1. Make real game natives callable from the JASS test binary.
2. Convert inventory tests first, since they already map cleanly to UnitItemInSlot / UnitHasItem style checks.
3. Convert hero, unit-flag, player, alliance, and group tests next.
4. Delete the C tests that are fully replaced by .j coverage.
5. Remove dead harness helpers and unused stubs as each migration makes them obsolete.
6. Trim the test build once the old callers are gone.

Good .j candidates

These are gameplay behaviors that map naturally to JASS natives:

• Inventory add/get and slot assignment
• Hero attributes, XP accumulation, and SuspendHeroXP
• Unit flags such as invulnerable, paused, hidden, and no-pathing
• Player properties like color, name, and team
• Alliances
• Ownership and range checks
• Group membership helpers

Keep in C

These areas do not have a meaningful Warcraft III gameplay-script surface and should stay as C tests:

• Pathfinding
• SLK parsing
• JASS VM internals
• Collision and physics
• UI / FDF rendering and serialization
• Network and server protocol
• Combat math that lives in shared engine/game code rather than gameplay scripting

Acceptance criteria

• At least one .j gameplay fixture exists and runs in CI.
• The JASS test binary can call the real game natives it needs.
• Replaced C tests are deleted once their .j equivalents exist.
• Harness code shrinks where helpers become unused.
• The build still passes for the remaining C-only suites.

Definition of done

• Gameplay tests are represented by .j fixtures instead of direct C harness calls where practical.
• The remaining C harness is smaller and easier to justify.
• The test suite is deterministic and self-contained.

[corepunch]

Concrete example: hero_inventory_test.j

Found in /tmp/hero_inventory_test.j (10 lines, by user):

native BJassAssert takes boolean cond, string msg returns nothing

function run_tests takes nothing returns nothing
    local location p = Location(0.0, 0.0)
    local unit u = CreateUnitAtLoc(Player(0), 'Hpal', p, 0.0)
    call BJassAssert(u != null, "hero created")
    call BJassAssert(UnitAddItemById(u, 'ratf') != null, "item added")
    call BJassAssert(UnitAddItemById(u, 'phea') != null, "second item added")
    call RemoveLocation(p)
endfunction

This is exactly the style we want to move toward. It exercises:

• Hero creation (CreateUnitAtLoc with Paladin 'Hpal')
• Inventory mutation (UnitAddItemById)
• Assertions on runtime game state

What it reveals about the gap

Every JASS native used here — Player, Location, CreateUnitAtLoc, UnitAddItemById, RemoveLocation — is a real Warcraft III common.j native (not a Blizzard.j wrapper). However, the JASS test binary's jass_funcs[] table in test_jass.c:92-106 currently registers only synthetic natives (NativeAdd, NativeMul, BJassAssert, Sleep, etc.) plus Player() for the player handle.

To run this test the following natives need to be reachable:

Native	Defined in	Status
Player	api_player.c	Already in jass_funcs[] ✅
BJassAssert	test's own native_BJassAssert	Already in jass_funcs[] ✅
Location	api_misc.c	Not registered ❌
RemoveLocation	api_misc.c	Not registered ❌
CreateUnitAtLoc	api_unit.c	Not registered ❌
UnitAddItemById	api_item.c	Not registered ❌

This confirms the key blocker described in the issue: the JASS test build needs to either link api_module.c (and its dependency tree) or selectively register the needed game natives in the test binary.

Where to put it

If this style is adopted, hero_inventory_test.j would live at:
games/warcraft-3/tests/fixtures/hero_inventory_test.j

And the test runner entry point (currently test_jass_main.c) would need to:

1. Load and parse all .j fixture files
2. Call run_tests() (or discover test functions via convention)
3. Assert that no JASS runtime error occurred

[corepunch]

Blocked by #116

The .j test migration described here depends on #116 — Add dedicated server mode (headless, no client).

The dedicated server provides the runtime environment for .j gameplay tests:

• Runs the real game module on a real server (no mocked gi, no hardcoded edicts)
• Executes JASS test scripts via map scripts or injected code
• Outputs BJassAssert results to stderr
• Exits cleanly after com_frame_limit frames

Without #116, .j gameplay tests would need the full client stack (SDL, renderer, sound, UI) to be present. With it, a test invocation is as simple as:

build/bin/openwarcraft3 -data build/tests/tests.mpq \
  +dedicated 1 +map Maps/Test/hero_inventory_test.w3m +com_frame_limit 1

Once #116 is merged, this issue can proceed with:

1. Creating test maps with .j test scripts as their war3map.j
2. Migrating inventory, hero, unit-flag, and alliance tests to .j fixtures
3. Removing the corresponding C tests from the harness
   BODY

[corepunch]

Implementation Plan (after #116 merges)

Architecture

The dedicated server provides the runtime for .j gameplay tests against the real game module:

tests.mpq
├── Maps/Test/hero_inventory_test.w3m   (real MPQ with war3map.j)
├── Maps/Test/unit_flags_test.w3m
├── TestUI/Textures/*.blp               (existing)
└── TestUI/Models/*.mdx                 (existing)

build/bin/openwarcraft3 -data build/tests/tests.mpq \
  +dedicated 1 +map Maps/Test/hero_inventory_test.w3m +com_frame_limit 1

The full path this exercises

SV_Init()
  → SV_Map(mapFilename)
    → ge->LoadMap(mapFilename)          // G_LoadMap in g_main.c
      → CM_LoadMap(mapFilename)         // common/world.c
        → SFileOpenArchiveFromMemory()  // opens .w3m as nested MPQ
        → CM_ReadHeightmap()            // war3map.w3e → world.map
        → CM_ReadInfo()                 // war3map.w3i → world.info
        → CM_ReadMapScript()            // war3map.j → JASS VM
    → ge->RunFrame()                    // every 100ms tick
      → jass_runevents(level.vm)        // runs JASS main()
        → BJassAssert(cond, msg)        // test assertions
  → exit(0) on success, exit(1) on failure

What blocks this

Gap	Fix
.w3m fixtures in resources-src/ are text files, not MPQs	Need a tool to create minimal .w3m MPQs
No .w3m generator exists	Write w3mgen or use mpqtool pack with binary fixtures
test-assets doesn't generate map MPQs	Add map generation to the build target

Minimal .w3m contents

A valid .w3m is an MPQ archive containing:

File	Required?	Notes
war3map.w3e	Yes	Heightmap — allocates world.map. Without it CM_GetHeightAtPoint crashes.
war3map.w3i	Yes	Map info — players, teams. Needed for lobby and game init.
war3map.j	Yes	JASS test script — contains main() with assertions.
war3map.doo	No	Doodads. Missing = warning only.
war3map.wpm	No	Pathmap. Missing = empty pathmap.
war3map.w3u	No	Unit overrides. Missing = defaults.
war3map.wts	No	Trigger strings. Missing = none.

war3map.w3e format (minimal)

struct heightmap_header {
    uint32 magic;           // 0x57334520 ("W3E ")
    uint32 version;         // 11
    char   tileset;          // 0 = Lordaeron Summer
    uint32 custom_flags;    // 0
};
// followed by ground texture array, cliff texture array,
// then width, height, center (vec2), and width*height vertex entries

war3map.w3i format (minimal)

struct map_info {
    uint32 version;         // 28+
    uint32 map_flags;       // 0
    uint32 map_width;       // e.g. 64
    uint32 map_height;      // e.g. 64
    char   map_name[32];    // "Test Map"
    char   map_subtitle[32];
    // player slots, teams, etc.
};

Steps

1. Write w3mgen tool — generates minimal .w3m MPQs with war3map.w3e + war3map.w3i + war3map.j
2. Add to test-assets — generate test maps and pack into build/tests/tests.mpq
3. Verify dedicated server — +dedicated 1 +map Maps/Test/hero_inventory_test.w3m +com_frame_limit 1 runs and exits cleanly
4. Migrate first test — convert hero_inventory_test from C harness to .j fixture
5. Delete replaced C tests — remove test_unit.c inventory coverage that's now in .j
6. Iterate — repeat for unit flags, hero XP, alliances, etc.

What stays in C (per issue description)

• Pathfinding, SLK parsing, JASS VM internals, collision, UI/FDF, network protocol, combat math in engine code

Key files

File	Role
server/sv_init.c:SV_Map()	Server map load entry point
server/sv_game.c:SV_InitGameProgs()	Loads game module via GetGameAPI
games/warcraft-3/game/g_main.c:GetGameAPI()	Game module entry
games/warcraft-3/game/g_main.c:G_LoadMap()	Calls CM_LoadMap + G_SpawnEntities
games/warcraft-3/common/world_w3.c:CM_LoadMapFormat()	Opens nested MPQ, reads war3map.* files
games/warcraft-3/game.mk:test-assets	Build target for tests.mpq