1

I'm working on a server for a very large (feature wise) MMO. After some bad experiences with breaking changes that caused bugs weeks down the line, we'd like to add unit/automated/regression tests to our project before we get much father (we've implemented approximately 5% of our requirements).

We haven't really used "serious" tests before (we've done the tutorial check-division-by-zero testing) so I thought I'd locate some guides for developing client-server test solutions. I was not able to find anything of much relevance. How should I deal with testing the following aspects of a typical server?

  • Testing the client-server communication (API can be broken down into "parsing", "handling" and "sending" stages)
  • Testing changes to an SQL database
  • Testing security measures
  • Testing around security measures (ie, making sure our tests don't trip our own security code)
  • Testing timed events

In case it's relevant, our language is C#, .Net 4.5

  • @gnat I can edit it to request actual answers here, but couldn't that get too broad? – Xcelled Jul 29 '14 at 14:47
  • I think if you just wipe out "gimme resource" part and don't add "just help me to get started", it ain't going to get broader than it currently is – gnat Jul 29 '14 at 14:54
  • @gnat How's that? Also, how 2 request removal of on hold status? – Xcelled Aug 1 '14 at 20:12
  • your edit is just what I was thinking about. As for "request to reopen", your edit did just that: meta.stackexchange.com/a/196078/165773 – gnat Aug 1 '14 at 20:18
2

Automated testing should be all about testing smallest pieces of functionality in as big isolation as possible. This allows you to define tests clearly, define most of the edge cases and have tests run in short time. Trying to test through multiple layers of code results in unclear tests, hard to test edge cases and tests that might take days to run.

So I would recommend to immediately drop the idea of testing the whole "server" as one big bulk of functionality from request handling to game logic. Instead, try to pinpoint the most error-prone code and test just that in as much isolation as possible. This would probably require refactoring, because code that is written without automated tests in mind is rarely testable. That way, you don't have to worry about most of the things on your list.

  • I agree with the use of unit tests, but they should be combined with automated integration and system tests, as well. Integration tests test how units work when combined (so it could test a small subsystem) while system tests test the entire system (basically a bigger integration test). How easy it is to create such a test, however, will depend on what is being tested. Some software may not have a way to do automated system testing (testing graphical games, for example). – Kat Aug 2 '14 at 3:02
  • @Mike The point of integration and system tests is not to test the system as a whole. But only test if individual components are connected properly. So there will be few of them and they will cover only few cases, compared to unit tests. – Euphoric Aug 2 '14 at 5:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.