HubConnection interface

[turowicz]

In contrast to the "full" SignalR, Core one doesn't have a HubConnection that would be possible to Mock. There is no interface for it.

https://github.com/aspnet/AspNetCore/blob/master/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs#L36

[turowicz]

Having similar problems with mocking WithUrl method on the IHubConnectionBuilder. Moq doesn't support extension methods.

It's as if nobody considered unit testing when designing contracts for Signalr.

[halter73]

We should definitely consider making more HubConnection methods virtual.

As for WithUrl, that is already mockable. It's true you cannot override the static extension method yourself, but you can the configured URL as follows after calling WithUrl:

HubConnectionBuilder.WithUrl("https://example.com/");
var configuredUri = HubConnectionBuilder.Services.BuildServiceProvider()
                        .GetService<IOptions<HttpConnectionOptions>>().Value.Url;
Assert.Equal(new Uri("https://example.com/"), configuredUri);

This should work either with a real HubConnectionBuilder or any mocked IHubConnectionBuilder with a realistic IServiceCollection implementation. Even if you you wind up providing a custom IHubConnectionBuilder.Build() implementation, I would recommend just using the default IServiceCollection implementation which is really just a thin wrapper around List<ServiceDescriptor>.

[turowicz]

@halter73 I think you should put it behind an interface and don't base your code architecture on extension methods as they are pain to work with.

We build mission-critical systems that people's lives depend on. We simply cannot work with a technology that is not unit testable.

[davidfowl]

@turowicz you can always wrap the hub connection in your own interface.

[analogrelay]

Can you provide an example of the test you want to perform? Understanding what kind of mocking you want here would be helpful. Adding interfaces makes the framework code itself much more brittle to breaking changes over time, so we don't just introduce them for testability purposes (when it's always feasible to write a wrapper if you need to do this kind of unit testing).

[analogrelay]

Closing this as we haven't heard from you and generally close issues with no response after some time. Please feel free to comment if you're able to get the information we're looking for and we can reopen the issue to investigate further!

[turowicz]

@anurse @davidfowl I will follow your best practice of wrapping everything into interfaces myself.