Move ComponentHubReliability tests to unit and E2E tests #32834
Conversation
ghost
added
the
captainsafia
force-pushed
the
safia/ch-unit-tests
branch
from
64df102 to
e63ee59
Compare
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
captainsafia
force-pushed
the
safia/ch-unit-tests
branch
from
db438a6 to
7f6ae32
Compare
| var serviceScope = new Mock<IServiceScope>(); | ||
| var circuitHost = TestCircuitHost.Create( | ||
| serviceScope: new AsyncServiceScope(serviceScope.Object)); | ||
| return circuitHost; |
There was a problem hiding this comment.
I'm not as familiar with the flow of these tests as you are, but is there any value in validating that the circuitKey is correct? For example storing the value supplied on the SetCircuit call and using that to decide whether to return null or not from here.
No big deal.
There was a problem hiding this comment.
For this particular case, I don't believe it provides a ton of value.
The circuit key is computed on a per-connection basis (so essentially on per circuit) so in real world scenarios it's not likely to be incorrect since there's only ever one value.
That and we don't really fully exercise the per-connection logic in this scenario. If there were issues with this codepath, they'd show up as failing server-side tests.
| @@ -16,7 +16,7 @@ | |||
|
|
|||
| namespace Microsoft.AspNetCore.Components.Server.Circuits | |||
| { | |||
| internal class CircuitFactory | |||
| internal class CircuitFactory : ICircuitFactory | |||
There was a problem hiding this comment.
| internal class CircuitFactory : ICircuitFactory | |
| internal sealed class CircuitFactory : ICircuitFactory |
| @@ -69,7 +72,7 @@ public override Task OnDisconnectedAsync(Exception exception) | |||
| { | |||
| // If the CircuitHost is gone now this isn't an error. This could happen if the disconnect | |||
| // if the result of well behaving client hanging up after an unhandled exception. | |||
| var circuitHost = GetCircuit(); | |||
| var circuitHost = _circuitHandleRegistry.GetCircuit(Context.Items, CircuitKey); | |||
There was a problem hiding this comment.
Couldn't we configure Context.Items instead of introducing the registry?
There was a problem hiding this comment.
The original intent here was to have an injected type that we could mock in the tests to avoid actually have to created a circuit instance. This originally started out as a singleton service with its own internal dictionary. However, that doesn't work because Context.Items is set up to correctly exist at a connection scope so I set up the registry as a wrapper around Context.Items with the ability to override in the code.
It's not possible for us to configure Context.Items directly in the test since the setting/getting happens entirely within the StartCircuit invocation so it's not possible to set up/tear down ahead of time.
Co-authored-by: Pranav K <[email protected]>
Fixes #19666
CircuitFactory.CreateCircuitHostAsyncvirtual to allow mocking in unit tests. This method does the bulk of the work around initializing a circuit host and setting up the dependent services.ComponentHubmethod unsealed and make certain methods virtual. This is done to make it easier to mock out parts of the API that are responsible for setting up connections.ComponentHubTestunit tests.