Is there a test suite for custom SignalR clients?

[SigmaTel71]

Forwarding my question from Stack Overflow here.

I'm making a custom SignalR client in C++ due to the official one being abandoned including its dependencies. I would like to test my client library against some form of test suite that implements whatever valid SignalR can output to the client in all protocols it has. Is there any?

[MentalOfCrow]

There is not currently a standalone, language-neutral SignalR client conformance package in the ASP.NET Core repository. However, the repository contains the pieces needed to build a useful conformance harness for a C++ client.

1. Treat the protocol specifications as the normative layer

• Hub protocol (handshake, JSON and MessagePack messages, streaming, cancellation, stateful reconnect messages):
  https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/docs/specs/HubProtocol.md
• Transport protocols (WebSockets, SSE, long polling and negotiation behavior):
  https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/docs/specs/TransportProtocols.md

The handshake deserves its own tests: it is always JSON, must be the first message, and is terminated by 0x1e, even when the selected hub protocol is MessagePack.

2. Reuse the official serialization vectors

The protocol test bases contain concrete valid and invalid frames for every hub message type. They are the closest thing to a reusable protocol test corpus:

• JSON vectors and parser cases:
  https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/SignalR.Common/test/Internal/Protocol/JsonHubProtocolTestsBase.cs
• MessagePack vectors (the binary payloads are stored as Base64):
  https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/SignalR.Common/test/Internal/Protocol/MessagePackHubProtocolTestBase.cs
• Handshake cases:
  https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/SignalR.Common/test/Internal/Protocol/HandshakeProtocolTests.cs

I would extract those cases into language-neutral fixtures such as JSON metadata plus raw/base64 wire payloads. For each fixture, test both directions:

1. your C++ decoder maps the frame to the expected semantic message;
2. your encoder produces a frame that the ASP.NET Core implementation accepts.

Also include malformed/truncated frames, unknown message types, extra data, duplicate invocation IDs, completion-with-result-and-error, record separators, and multiple messages in one receive buffer.

3. Run interoperability tests against the official server

Microsoft’s own client functional tests start a real ASP.NET Core server and exercise JSON/MessagePack over WebSockets, SSE and long polling. The test host and endpoints are here:

• test server configuration:
  https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/clients/csharp/Client/test/FunctionalTests/Startup.cs
• client interoperability scenarios:
  https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/clients/csharp/Client/test/FunctionalTests/HubConnectionTests.cs

You can create a small .NET test-server executable modeled on that Startup.cs, launch it from CTest/CI on an ephemeral port, then run the C++ client through this matrix:

• negotiation and skipNegotiation where applicable;
• JSON and MessagePack;
• WebSockets, SSE and long polling;
• invoke/send, server-to-client invocation and completion errors;
• download/upload streaming and cancellation;
• reconnect and timeouts;
• headers, access tokens, redirects and close messages.

This gives you three separate guarantees: codec correctness from the vectors, state-machine correctness from negative tests, and real interoperability against the current ASP.NET Core server. Pin the ASP.NET Core commit used to obtain the fixtures, and periodically test against the latest supported release so protocol changes are visible rather than silently changing your expected data.

If this resolves what you were looking for, you can mark it as the accepted answer so future client implementers can find the test approach quickly.