Testing Strategy

Nodalite's tests follow one rule: prefer a real integration test over a mocked one wherever it's cheap to run.

Per-package approach

adapter-node

Tests start a real http.Server on an OS-assigned port and hit it with a real fetch() — not a simulated request object.

adapter-lambda

Tests use realistic API Gateway v1/v2 event fixtures, not simplified stand-ins, so a real shape mismatch would actually fail.

workers

Tests spawn real worker_threads, including a real crash-and-restart cycle with real timing — not a mocked Worker class.

ml

Tests spin up a real local HTTP server to verify actual disk caching of downloaded model bytes. The ~270MB onnxruntime-node dependency is replaced with a fake InferenceEngine implementing the same two-method interface. Additional tests cover path traversal rejection, file size limit enforcement, extension validation, and ONNX magic-byte verification — all using real filesystem operations, not mocks.

core

Unit tests for the router, middleware compose, error handling, and validation logic, plus integration tests that exercise the full request pipeline.

Running tests

# All packages
npm test

# Single package
npm test -w @nodalite/core

Why not mocked tests?

Mocking hides real problems:

• Changes in the runtime's worker_threads API that break your worker code
• Differences between your simulated Lambda event and a real one
• Timing issues that only show up with real network calls

When a real dependency is genuinely too heavy (native binaries, large models), the code is still written against its real API — only the test uses a fake, so the logic under test (caching, dedup, warm reuse) is validated for real.