dimanche 12 août 2018

What's a good way of testing a game network layer based on System.Net.Sockets.UdpClient?

I'm building my own networking layer based on UDP (for a semi-realtime game), and I'm wondering what's the right approach for testing this. It implements basic features such as reliable/semi-reliable/unreliable datagram delivery, timeouts, acks, etc.

It seems there are basically two approaches I can take. Either abstract away UdpClient behind an interface and provide the network layer with a mock implementation at test time. Or actually do all of the UDP logic inside the tests.

I don't really care for things like "test purity", or if what I'm doing is "unit testing" or "integration testing". I don't mind just doing one or the other, as long as it gives me enough confidence in my logic. Since there are quite a few edge cases and timing-related stuff that can happen, I intend to write quite a few tests. One thing that might be relevant and will definitely be useful is that everything is synchronized to a manually controlled game loop. Which means my network layer has an Update(deltaTime) which is how it gets to calculate its own timeouts and all scheduling logic related to re-sending etc, which means I can have some control over how time passes during the test.

What are the downsides of each approach and which one would you recommend? And ideally, if you're in favor of using a mock UdpClient, is there any such thing already available?

Aucun commentaire:

Enregistrer un commentaire