chore: proper integration testing no funny business, no lying, no global foot gunning

[nadr0]

closes #8377

Issue

I made a massive integration.spec.ts because the engine connection code and WASM loaders were not stable with multiple files spamming initPromise()

Implementation

• Properly split each file
• Each file will initialize all its dependencies locally
• Limit or totally remove the global dependencies
• unitTestUtils.ts implements buildTheWorldAndConnectToEngine and buildTheWorldAndNoEngineConnection
• Load WASM instance off disk with read file instead of localhost:3000

  const WASM_PATH = join(process.cwd(), 'public/kcl_wasm_lib_bg.wasm')
  const instance = await loadAndInitialiseWasmInstance(WASM_PATH)

• Every single it( test can build the world and do engineCommandManager.tearDown()
• Every single initPromise() spam will have a Promise.resolve() but say it failed so all of the tests will brick unless you build the world
• Maybe functions, code paths, classes now accept optional arguments for different amounts of the "world".

Even though an entire .spec.ts file can have each it( test build the world with engine connection and destroy it that is super resource intensive so a single file will do this at the start and destroy at the end. This is not the same as using global singletons imports. Everything is still created locally within that file and passed to all the it( tests.

• Tests that do not use the engine connection will build the world each it( since it is all based on memory usage not the remote engine connection.

• Each test that needs only a WASM instance will build it again since you read off disk and then store an instance of it in memory.

• All *.spec.ts(x) files are migrated

• npx vitest run --mode development --no-file-parallelism --project integration will run all the tests with 1 file at a time.

• Massive wasmInstance?: ModuleType spammed in every helper function

• huge update to the modelingMachine to use the context and the provided ones over the global ones

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
modeling-app	Ready	Preview	Comment	Oct 21, 2025 4:40pm

💡 Enable Vercel Agent with $100 free credit for automated AI reviews

[jacebrowning]

Just checking, do the integration tests still need a real web browser?

[nadr0]

I do not think so? https://vitest.dev/guide/browser/

I am trying to see if it is possible to configure a browser with vitest. I honestly do not think we have this integration enabled. I checked the vitest.config.ts

[jacebrowning]

Yeah, seems like we don't need the browser. For review to merge into this branch: #8622

[jacebrowning]

Actually, I changed my mind and marked that as a draft based on this conversation. Ideally, the npm-test-unit job doesn't need Wasm at all.

[nadr0]

Correct. The proper way to solve this would be dependency injection and not directly importing WASM functions from that binding.

Our application today does not do dependency injection so the dependency must exist for the unit test to import even if my unit test is not directly using it. The import/export builder step will crash.

[jacebrowning]

Great work on this!