test: get zig build test working

[DonIsaac]

What does this PR do?

Lets us write and run unit tests directly in Zig.

Running Zig unit tests in CI is blocked by ziglang/zig#23281. We can un-comment relevant code once this is fixed.

Workflow

I'll finish writing this up later, but some initial points are below.
Tl;Dr: bun build:test

Test binaries can be made for any kind of build. They are called <bun>-test and live next to their corresponding bun bin. For example, debug tests compile to build/debug/bun-debug-test.

Test binaries re-use most cmake/zig build steps from normal bun binaries, so building one after a normal bun build is pretty fast.

How did you verify your code works?

I tested that my tests run tests.

[robobun]

^{Updated 4:40 PM PT - Mar 19th, 2025}

❌ @DonIsaac, your commit 0e2e639 has 1 failures in Build #13541:

• test/cli/install/bun-install-registry.test.ts - 1 failing on 🪟 2019 x64-baseline
• test/cli/install/bun-install-registry.test.ts - 1 failing on 🪟 2019 x64

---

🧪   try this PR locally:

bunx bun-pr 18207

[190n]

I'm skeptical of this. Recovering from panics isn't really intended to be possible or supported. IMO we should just let it crash, or if we really need fine-grained panic reporting in CI we could run each test in a new process using a filter.

[DonIsaac]

IDk, I'd personally rather have my test suite finish running all tests instead of aborting early when one of them panics. Thoughts?

[190n]

I'm concerned that panic recovery will fail or cause unexpected results, since this isn't really something Zig has put time into making possible:

• Proposal: Add a way for a test to expect a panic ziglang/zig#1356
• Safely working with libraries that use setjmp/longjmp ziglang/zig#1656 (comment) (recover.zig uses setjmp/longjmp or functions with the same issues)

So realistically it could mess up tests that run after the panic. But I guess that might not be terrible for a worst-case scenario since you will just see that fixing the panic causes the tests after it to work again.