This repository has two automated test entry points:
src/Test.Automatedsrc/Test.XUnit
It also includes a benchmark harness:
src/Test.Benchmark
It also includes interactive websocket sample applications:
src/Test.WebsocketServersrc/Test.WebsocketClient
Test.Automated is the primary automated console suite. It contains the migrated legacy coverage plus the added optimization-safety coverage.
Run it with:
dotnet run --project src\Test.Automated\Test.Automated.csprojBehavior:
- Prints one normalized pass/fail line per test
- Prints an overall pass/fail summary with total runtime
- Enumerates failed tests at the end when failures occur
The websocket shared scenarios are also surfaced through Test.Automated via SharedCoreUnitCoverageSuite.
Run the full automated suite:
dotnet run --project src\Test.Automated\Test.Automated.csprojIf you want to inspect the websocket case names first, refer to:
src/Test.Shared/SharedWebSocketTests.cssrc/Test.Automated/SharedCoreUnitCoverageSuite.cs
Test.XUnit is the CI-oriented xUnit runner. It shares reusable logic through Test.Shared and does not invoke Test.Automated.
The stable execution flow is:
powershell -ExecutionPolicy Bypass -File src\Test.XUnit\Run-Test.XUnit.ps1That script performs these steps:
- Builds
src/Test.XUnit/Test.XUnit.csproj - Executes
dotnet test --no-build
If you want console output that shows each xUnit test with its pass/fail result and runtime, run:
dotnet test src\Test.XUnit\Test.XUnit.csproj --no-build -c Debug -f net10.0 --logger "console;verbosity=detailed"Notes:
verbosity=detailedis what causes per-test output to appear--no-buildkeeps the console output focused on test execution if the project is already built- omit
--no-buildif you wantdotnet testto build first
The current websocket shared scenarios are surfaced through Test.XUnit and Test.Automated.
For the focused websocket-oriented xUnit slice:
dotnet test src\Test.XUnit\Test.XUnit.csproj -c Debug --filter SharedCoreUnitCasePassesFor a detailed console listing of each websocket shared case:
dotnet test src\Test.XUnit\Test.XUnit.csproj --no-build -c Debug -f net10.0 --filter SharedCoreUnitCasePasses --logger "console;verbosity=detailed"Test.Benchmark is the performance harness used to compare Watson 7 against Watson 6, WatsonLite6, and Kestrel across supported protocols and scenarios.
Run it with:
dotnet run --project src\Test.Benchmark\Test.Benchmark.csproj -- --targets all --protocols http1,http2,http3 --scenarios hello,jsonBehavior:
- Prints one formatted line per benchmark combination during the live run
- Prints a summary table after completion
- Prints protocol comparison tables after the summary
Useful examples:
dotnet run --project src\Test.Benchmark\Test.Benchmark.csproj -- --targets watson7 --protocols http1 --scenarios hello,json --warmup-seconds 2 --duration-seconds 5 --concurrency 16
dotnet run --project src\Test.Benchmark\Test.Benchmark.csproj -- --targets all --protocols http3 --scenarios echo,json-echo --warmup-seconds 2 --duration-seconds 5 --concurrency 16Websocket benchmark examples:
dotnet run --framework net10.0 --project src\Test.Benchmark\Test.Benchmark.csproj -- --targets watson7 --protocols http1 --scenarios websocket-echo --warmup-seconds 1 --duration-seconds 1 --concurrency 2
dotnet run --framework net10.0 --project src\Test.Benchmark\Test.Benchmark.csproj -- --targets watson7 --protocols http1 --scenarios websocket-connect-close,websocket-client-text,websocket-server-text --warmup-seconds 1 --duration-seconds 1 --concurrency 2Notes:
Watson6,WatsonLite6, andKestrelavailability depends on the selected protocol and scenario- some combinations are intentionally skipped when the harness does not support them
- HTTP/3 benchmarking depends on local QUIC support
- WebSocket benchmarking currently targets Watson 7 on HTTP/1.1 only
- Current websocket scenarios include echo/request-reply, connect-close, client-to-server text with ack, and server-to-client text after a trigger
Test.WebsocketServer is a menu-driven websocket host for manual validation. It exposes HTTP routes plus websocket routes and allows:
- listing active websocket clients
- kicking a connected client
- sending one or many unsolicited messages to a selected client
- sending a message to all connected clients
Run it with:
dotnet run --project src\Test.WebsocketServer\Test.WebsocketServer.csprojTest.WebsocketClient is a menu-driven websocket client for manual validation. It supports:
- endpoint presets and custom URIs
- custom request headers
- requested subprotocols
- text, burst-text, and binary sends
- explicit close with status and reason
- background receive logging
Run it with:
dotnet run --project src\Test.WebsocketClient\Test.WebsocketClient.csprojWebSocket coverage in the current repository is primarily validated against loopback ws:// paths.
Important notes:
wss://manual validation requires a certificate and SSL-enabled Watson configuration- HTTP/2 and HTTP/3 websocket runtime scenarios are not yet implemented
- Browser-oriented websocket validation is still pending; current automated validation uses
ClientWebSocket - HTTP/3 benchmarks and tests depend on local QUIC support
Wrapper for the full stable xUnit flow.
For direct coverage validation during development:
dotnet run --project src\Test.Automated\Test.Automated.csprojFor CI-style xUnit validation in this repository:
powershell -ExecutionPolicy Bypass -File src\Test.XUnit\Run-Test.XUnit.ps1For local xUnit runs where you want to see each test result and elapsed time:
dotnet test src\Test.XUnit\Test.XUnit.csproj --no-build -c Debug -f net10.0 --logger "console;verbosity=detailed"For local performance validation:
dotnet run --project src\Test.Benchmark\Test.Benchmark.csproj -- --targets watson7 --protocols http1,http2,http3 --scenarios hello,json,echo,json-echo