C
C#•4w ago
gax

Best way to test something that depends on a ClientWebSocket

In one of our services, we use ClientWebSocket to send over some data, however we now need to write integration tests for said services. The current setup basically creates the service from a factory method that reads some config from an environment variable and the scoped service instantiates a new client to connect to said websocket, do the job it's supposed to and dispose thereafter. I am fairly new to this codebase and thankfully have the freedom to change it if necessary, primarily because the codebase is only a few months old as well I've never worked with WebSockets like this either so any extra feedback on how to improve this code would be great The initialization is as follows: 
    private MyService(string serverUrl)
    {
        _serverUri = new Uri(serverUrl);
        _webSocket = new ClientWebSocket();
        _cts = new CancellationTokenSource();
    }
    private MyService(string serverUrl)
    {
        _serverUri = new Uri(serverUrl);
        _webSocket = new ClientWebSocket();
        _cts = new CancellationTokenSource();
    }
Then, we connect to the server by calling the following method 
    public async Task ConnectAsync()
    {
        if (_webSocket.State == WebSocketState.Open) return;

        await _webSocket.ConnectAsync(_serverUri, CancellationToken.None).ConfigureAwait(false);
    }
    public async Task ConnectAsync()
    {
        if (_webSocket.State == WebSocketState.Open) return;

        await _webSocket.ConnectAsync(_serverUri, CancellationToken.None).ConfigureAwait(false);
    }
Obviously theres some more logic to it, however removed due to being unrelated to this specifically I initially thought of writing a super simple interface with a thin wrapper around the client then inject it via DI, though i'm not sure if that's the best way
5 Replies
dance?
dance?•4w ago
it's kinda difficult to give advice considering the only thing you say is "we use a websocket", the matter needs a bit more details
gax
gaxOP•4w ago
i mean im happy to give as much detail as i can we basically use websockets to keep sending data that is processed and generated a couple hundred times a second, we batch the data and send it over via said socket the websocket is used directly inside the service as shown there, being recreated whenever the connection is lost (handled by our reconnection logic, which if possible id like to also get tests set up for) the processing uses a thread safe queue and only dequeues if the message is "sent" (we assume its sent if it doesnt throw), otherwise we handle those errors
dance?
dance?•4w ago
the fact that you are expressing doubts means there is no currently other test suite or procedure in act? depending on what this service does there could be a self-test method inside the services or you could have a separate program that pokes this service; i usually tend to do the last writing an interface would be superfluous if as i understand you intend to test the whole service itself what would you like to test, timeout, throughput, protocol?
gax
gaxOP•4w ago
the fact that you are expressing doubts means there is no currently other test suite or procedure in act?
exactly, the tests here mainly consists of "if the frontend devs arent complaining then it works" and we're in the process of changing that
what would you like to test
primarily test the data processing inside the service, as well as behaviours when X situation happens like the connected server going down without properly closing socket connection the main objective is honestly just making sure a critical service is resilient enough for possible situations that could cause outages
dance?
dance?•4w ago
ok so this looks like a relatively common case of writing a test service with test cases (maybe at this stage it could still be written with vs test units but personally i would rather go with an isolated project)

Did you find this page helpful?