Testing — xunit inside the mesh

In MeshWeaver a NodeType can be defined as data: its C# lives in the node's Source/ folder and the mesh compiles it live. Its tests live beside it, in Test/*.cs, and are compiled the same way — inside the running portal. A portal does not ship the xunit test framework, so without help an in-mesh test cannot say using Xunit;, and a NodeType whose tests do not compile does not compile at all.

This package closes that gap. It is for developers who write NodeTypes and want their tests in the vocabulary they already know.

What you may write once it is installed

using Xunit;

public class TariffTests
{
    [Fact]
    public void ARateIsNeverNegative() => Assert.True(Tariff.Rate("CH") >= 0);

    [Theory]
    [InlineData("CH")]
    [InlineData("DE")]
    public void EveryRegionHasARate(string region) => Assert.InRange(Tariff.Rate(region), 0, 1);
}

[Fact], [Theory], [InlineData] and Assert compile. The package also carries a small per-case helper set — MeshWeaver.Testing.TestContext, SkipException and TestLog — so a test can read its context, skip itself with a reason and write to the case's log.

⚠️ Compiling is not running. The package adds compiler references, not xunit's discovery or execution: nothing in the mesh finds [Fact] methods or expands [Theory] rows by itself. The node-test harness discovers only public static parameterless methods of a static class whose name ends in Tests, so the instance methods above run there as zero tests, reported green. To run them, the NodeType's Tests layout area must call each case explicitly — one row per [Fact], and one row per [InlineData] set of a [Theory] — and render the pass/fail table.

How it works

Every installed module joins the reference set that in-mesh source is compiled against. Installing this package therefore makes xunit's types referenceable from any NodeType's Test/ folder, with no change to the compiler and nothing added to the portal for installations that do not use it.

Three rules

1. Install, then restart. Installed modules join the compile reference set when the portal starts. Installing on a running portal lands the package, but using Xunit; compiles only after the next start. Land NodeTypes whose tests use xunit after that restart, not in the same step.
2. Declare the dependency. A package whose in-mesh tests use xunit lists it in its root's requires, for example "requires": ["Store@^1.0.0", "Testing@^1.0.0"]. An undeclared dependency does not fail loudly; a node whose module is missing cannot activate, and the read waits for its full timeout.
3. Expose a Tests area. A NodeType shows its suite through a Tests layout area that runs the cases and renders a pass/fail table, so the result can be read in the portal and asserted by a build.

End-to-end executable specs

The package also carries the platform's end-to-end specs: suites that run as a job routed to a pre-installed test instance and go red on exactly the capabilities that have not landed yet.

• Document ingestion — attach a container, create or wait for its table, ingest exactly once, label and index.
• Complex flows — ask and await, retry then flag, unblock through triage, correlate.
• Connecting storage — attach a container to a partition, approve, resume, read under the partition's grants and detach.
• How they run — the shared kit, the contract and how a domain plugs in its own scenario.

What you get

The package is in the free tier. Getting it adds the xunit runtime for in-mesh tests and the end-to-end spec types. The engineering detail — the measurements behind it and its known limits — is in Testing internals for subscribers.