Testing SignalR Applications with Integration Tests

Testing SignalR Applications with Integration Tests

by | Apr 2, 2025 | Testing

In the last days, I have been dealing with a chat prototype that uses SignalR. I’ve been trying to follow the test-driven development (TDD) approach as I like this design pattern. I always try to find a way to test my code and define use cases so that when I’m refactoring or writing code, as long as the tests pass, I know everything is fine.

When doing ORM-related problems, testing is relatively easy because you can set up a memory provider, have a clean database, perform your operations, and then revert to normal. But when testing APIs, there are several approaches.

Some approaches are more like unit tests where you get a controller and directly pass values by mocking them. However, I prefer tests that are more like integration tests – for example, I want to test a scenario where I send a message to a chat and verify that the message send event was real. I want to show the complete set of moving parts and make sure they work together.

In this article, I want to explore how to do this type of test with REST APIs by creating a test host server. This test host creates two important things: a handler and an HTTP client. If you use the HTTP client, each HTTP operation (POST, GET, etc.) will be sent to the controllers that are set up for the test host. For the test host, you do the same configuration as you would for any other host – you can use a startup class or add the services you need and configure them.

I wanted to do the same for SignalR chat applications. In this case, you don’t need the HTTP client; you need the handler. This means that each request you make using that handler will be directed to the hub hosted on the HTTP test host.

Here’s the code that shows how to create the test host:



// ARRANGE
// Build a test server
var hostBuilder = new HostBuilder()
    .ConfigureWebHost(webHost =>
    {
        webHost.UseTestServer();
        webHost.UseStartup<Startup>();
    });

var host = await hostBuilder.StartAsync();

//Create a test server
var server = host.GetTestServer();





And now the code for handling SignalR connections:


         // Create SignalR connection
         var connection = new HubConnectionBuilder()
             .WithUrl("http://localhost/chathub", options =>
             {
                 // Set up the connection to use the test server
                 options.HttpMessageHandlerFactory = _ => server.CreateHandler();
             })
             .Build();

         string receivedUser = null;
         string receivedMessage = null;

         // Set up a handler for received messages
         connection.On<string, string>("ReceiveMessage", (user, message) =>
         {
             receivedUser = user;
             receivedMessage = message;
         });





//if we take a closer look, we can see the creation of the test handler "server.CreateHandler"
var connection = new HubConnectionBuilder() .WithUrl("http://localhost/chathub", options => 
{ 
// Set up the connection to use the test server 
options.HttpMessageHandlerFactory = _ => server.CreateHandler(); 
}) .Build();


 


Now let’s open a SignalR connection and see if we can connect to our test server:


          string receivedUser = null;
          string receivedMessage = null;

          // Set up a handler for received messages
          connection.On<string, string>("ReceiveMessage", (user, message) =>
          {
              receivedUser = user;
              receivedMessage = message;
          });

          // ACT
          // Start the connection
          await connection.StartAsync();

          // Send a test message through the hub
          await connection.InvokeAsync("SendMessage", "TestUser", "Hello SignalR");

          // Wait a moment for the message to be processed
          await Task.Delay(100);

          // ASSERT
          // Verify the message was received correctly
          Assert.That("TestUser"==receivedUser);
          Assert.That("Hello SignalR"== receivedMessage);

          // Clean up
          await connection.DisposeAsync();


 


You can find the complete source of this example here: https://github.com/egarim/TestingSignalR/blob/master/UnitTest1.cs


 

				
					

			
					


				
															
Choosing the Right JSON Serializer for SyncFramework

					
					
 by  | Jun 6, 2024 | Data Synchronization
Choosing the Right JSON Serializer for SyncFramework: DataContractJsonSerializer vs Newtonsoft.Json vs System.Text.Json


When building robust and efficient synchronization solutions with SyncFramework, selecting the appropriate JSON serializer is crucial. Serialization directly impacts performance, data integrity, and compatibility, making it essential to understand the differences between the available options: DataContractJsonSerializer, Newtonsoft.Json, and System.Text.Json. This post will guide you through the decision-making process, highlighting key considerations and the implications of using each serializer within the SyncFramework context.


Understanding SyncFramework and Serialization


SyncFramework is designed to synchronize data across various data stores, devices, and applications. Efficient serialization ensures that data is accurately and quickly transmitted between these components. The choice of serializer affects not only performance but also the complexity of the implementation and maintenance of your synchronization logic.


DataContractJsonSerializer


DataContractJsonSerializer is tightly coupled with the DataContract and DataMember attributes, making it a reliable choice for scenarios that require explicit control over serialization:


    

  • Strict Type Adherence: By enforcing strict adherence to data contracts, DataContractJsonSerializer ensures that serialized data conforms to predefined types. This is particularly important in SyncFramework when dealing with complex and strongly-typed data models.
    • 

  • Data Integrity: The explicit nature of DataContract and DataMember attributes guarantees that only the intended data members are serialized, reducing the risk of data inconsistencies during synchronization.
    • 

  • Compatibility with WCF: If SyncFramework is used in conjunction with WCF services, DataContractJsonSerializer provides seamless integration, ensuring consistent serialization across services.
    • 



When to Use: Opt for DataContractJsonSerializer when working with strongly-typed data models and when strict type fidelity is essential for your synchronization logic.


Newtonsoft.Json (Json.NET)


Newtonsoft.Json is known for its flexibility and ease of use, making it a popular choice for many .NET applications:


    

  • Ease of Integration: Newtonsoft.Json requires no special attributes on classes, allowing for quick integration with existing codebases. This flexibility can significantly speed up development within SyncFramework.
    • 

  • Advanced Customization: It offers extensive customization options through attributes like JsonProperty and JsonIgnore, and supports complex scenarios with custom converters. This makes it easier to handle diverse data structures and serialization requirements.
    • 

  • Wide Adoption: As a widely-used library, Newtonsoft.Json benefits from a large community and comprehensive documentation, providing valuable resources during implementation.
    • 



When to Use: Choose Newtonsoft.Json for its flexibility and ease of use, especially when working with existing codebases or when advanced customization of the serialization process is required.


System.Text.Json


System.Text.Json is a high-performance JSON serializer introduced in .NET Core 3.0 and .NET 5, providing a modern and efficient alternative:


    

  • High Performance: System.Text.Json is optimized for performance, making it suitable for high-throughput synchronization scenarios in SyncFramework. Its minimal overhead and efficient memory usage can significantly improve synchronization speed.
    • 

  • Integration with ASP.NET Core: As the default JSON serializer for ASP.NET Core, System.Text.Json offers seamless integration with modern .NET applications, ensuring consistency and reducing setup time.
    • 

  • Attribute-Based Customization: While offering fewer customization options compared to Newtonsoft.Json, it still supports essential attributes like JsonPropertyName and JsonIgnore, providing a balance between performance and configurability.
    • 



When to Use: System.Text.Json is ideal for new applications targeting .NET Core or .NET 5+, where performance is a critical concern and advanced customization is not a primary requirement.


Handling DataContract Requirements


In SyncFramework, certain types may require specific serialization behaviors dictated by DataContract notations. When using Newtonsoft.Json or System.Text.Json, additional steps are necessary to accommodate these requirements:


    

  • Newtonsoft.Json: Use attributes such as JsonProperty to map JSON properties to DataContract members. Custom converters may be needed for complex serialization scenarios.
    • 

  • System.Text.Json: Employ JsonPropertyName and custom converters to align with DataContract requirements. While less flexible than Newtonsoft.Json, it can still handle most common scenarios with appropriate configuration.
    • 



Conclusion


Choosing the right JSON serializer for SyncFramework depends on the specific needs of your synchronization logic. DataContractJsonSerializer is suited for scenarios demanding strict type fidelity and integration with WCF services. Newtonsoft.Json offers unparalleled flexibility and ease of integration, making it ideal for diverse and complex data structures. System.Text.Json provides a high-performance, modern alternative for new .NET applications, balancing performance with essential customization.


By understanding the strengths and limitations of each serializer, you can make an informed decision that ensures efficient, reliable, and maintainable synchronization in your SyncFramework implementation.