Tighten and standardize the test setup across packages

[tormnator]

Is your feature request or improvement related to a problem?

Yes, but this is low priority.

Nue's current test setup is workable and already covers a meaningful amount of behavior, but it does not feel fully standardized across packages yet. The repo currently has a mix of patterns and runners that make the overall testing story less consistent than it could be.

Examples observed while evaluating the repo:

• some packages use Bun directly while others still use Jest-based scripts
• some tests import APIs explicitly from bun:test, while others rely on test globals
• some browser-facing tests are skipped instead of following a stable test pattern
• some tests appear to rely on shared mutable state or order-sensitive setup
• coverage conventions are minimal beyond path ignore patterns

None of this makes the current setup unusable, but it does make it harder to point to a clear repo-wide testing model.

Solution you'd like

Track a gradual cleanup / standardization pass for the test setup across packages.

This does not need to be a big-bang migration. The goal is mainly to create a reference issue so incremental improvements can converge on a clearer testing story over time.

Suggested goals

• define a clearer repo-wide default testing style for Bun-based packages
• reduce avoidable differences between package-level test setups where practical
• make it easier to understand which older patterns are intentional and which are just historical leftovers
• keep test maintenance cost low while improving consistency

Areas worth tightening over time

1. Mixed test runners

There is currently a mix of Bun-based and Jest-based test scripts across the repo.

That may still be the right answer for some packages, but it would help to be clearer about:

• which packages are intentionally staying on Jest for now
• which packages are expected to use Bun going forward
• whether there is a long-term convergence plan or whether a mixed model is acceptable permanently

2. Test style consistency

Even within Bun-based tests, style is not fully uniform.

For example:

• some tests explicitly import from bun:test
• others rely on Bun globals

It would be useful to prefer one style by default so new tests follow a more predictable pattern.

3. Skipped or fragile browser-facing tests

Some browser-oriented tests are currently skipped. That is understandable, but it leaves a gap between the intended API surface and what is exercised reliably.

If those tests remain skipped, it would help to clarify whether:

• they are placeholders
• they are blocked on missing test utilities
• they should be replaced by a different testing approach

4. Shared state / order coupling

A few tests appear to rely on state that persists across test boundaries more than necessary.

It would be worth tightening setup/teardown patterns where possible so tests are more obviously isolated and less sensitive to execution order.

5. Coverage expectations

Coverage is configured at a minimal level today, but there does not seem to be a strong repo-level convention yet for:

• when to run coverage
• what is considered sufficient coverage
• whether thresholds or package-level expectations should exist

This may be fine, but the current baseline seems more implicit than explicit.

Alternatives you've considered

1. Leave everything as-is

This is defensible in the short term because the current tests are already useful.

The downside is that the repo may continue drifting toward a more fragmented setup that is harder to reason about later.

2. Large immediate migration

Probably not worth it.

A gradual approach is more realistic and less disruptive.

Additional context

This issue is intentionally low priority.

The current setup is a decent foundation, especially in the Bun-based packages. The main concern is consistency, maintainability, and future clarity rather than an urgent breakage.