Testing SignalR Connections with NUnit

The SignalR GitHub site has an example wherein a SignalR PersistentConnection instance is used from a non-HTML client. The idea of being able to use SignalR connections in applications other than those that run in a web browser raises some interesting challenges. Likewise, there aren’t too many examples on how to use SignalR connections. This post will demonstrate asynchronously testing a SignalR connection in an end-to-end scenario using NUnit.

Creating Custom SignalR Connections

The first step is to create a custom SignalR connection. For the purposes of this example a simple connection implementation will do just fine. Borrowing from the example on the SignalR GitHub site is the EchoConnectionclass below.

The implementation of the EchoConnectionshould be relatively self-explanatory. Whenever the connection receives a message from a client, it turns around and sends that message out to all the connected clients using the Broadcastmethod.


Unlike SignalR Hubs, which are automatically wired up and routed, SignalR Connection classes aren’t (at least, I don’t know that they are). There’s an additional step with SignalR connections; they must be routed similarly to how MVC routes or WCF Web API routes are set up. The code below is from an MVC 3.0 application’s Global.asax.csfile, but you could accomplish the same sort of thing using a custom module.

The point here is to define a route that will provide HTTP access to this connection class. Next, the client code needs to be written. That’ll be accomplished using an NUnit test (it’s really an integration test, but that’s semantic sugar).

Using the SignalR.Client NuGet Package

The example source code contains a simple class library project. This project references the SignalR.Client NuGet package to provide .NET client communication functionality to an application written in managed code. You can use the SignalR.Client project in your desktop applications or in back-end services or Azure Worker Roles. The class library project is shown below, so you can get an idea of the minimal dependencies necessary to support .NET client SignalR support.

SignalR.Client makes use of Newtonsoft.JSON, so that project gets pulled in automatically when you update your NuGet package references. Caveat/Gotcha: I had to explicitly redirect this class library project’s App.config file to the newest version of the Newtonsoft.JSON assembly. You might not need to do that, but just in case, here’s how.

Writing the Test

At this point, the project is properly set up and everything should be ready for setting up the unit (or integration, depending on your stance) test to communicate with the SignalR connection.

It is important to point out that this test makes use of the AutoResetEventclass to wait for the asynchronous process to complete. This is done because SignalR’s communication via either the connection or hub approach implies that the communication is asynchronous.

If this test is run when the web server is turned off, it will obviously fail, as the test output below from NUnit demonstrates.


Once the web server is started and the test re-run, the client receives a message almost as soon as it finishes sending it, and the test passes.



SignalR is an asynchronous messaging library designed to provide push-like functionality and continuous connectivity for web clients. However, it isn’t just for the web; SignalR connections can be used from within .NET code to provide instant communication and constant connectivity between multiple clients.

Happy coding!