Golang Nakama Testing - Guide

Runtime Framework
1

Any guide one could follow to be able to write some unit tests for the rpcs we have created for our game? Whats the suggestion for testing them?

2

Hello @BernardoSantos,

One approach is to do integration testing, so you could actually start the server using your custom code locally with Docker and then you’d have some Go tests that execute the RPCs through http calls.

Another option is to use a Go mock library, mock the modules that are injected by Nakama in the registered RPCs (runtime.NakamaModule, logger, etc) and test the functionality of the RPC with the mocked dependencies.

I believe there are some other threads around the forum on this topic.

3

I am using mocks but there must be a better way.

At the moment, I have to mock every single StorageRead/Write Input/Output manually.

On a method that reads/writes 20 different tables for example, thats a mess.
Even if there are tables that dont change, or the value doesnt matter.

4

There are scenarios which are very laborious to test by nature, I’ve personally used mocking in Go very sparingly (and without using any of the existing libraries), but I’d argue that for a test that relies heavily on the storage engine it’s easier and better to just populate the db with the required data and use integration tests for multiple reasons:

  • If you have to mock a lot of inputs/outputs, the mocks themselves may not reliably reproduce the behavior of the API, so the tests may not be reliable;
  • By using the APIs and/or your own wrapper functions that write the data to the DB, you’ll also be exercising that logic even if it’s not the scope of the test;
  • Actually going to DB will better represent the actual real application workload;
  • If you test via HTTP calls by inspecting the returned data, you’ll also end up testing that the data returned back to the client is correct;
  • If the data representation changes you may have to change all your mocks;

Personally (and this is just my own opinion, there’s a lot of opinionated literature around testing), I tend to prefer integration testing - it ends up covering a much bigger surface than unit tests. I’ll stick to unit tests for functions or smaller units where there’s few or no external dependencies to mock but the logic is complex enough that it’s justified.

In the end it’s a balancing act - you should decide which types of tests are better suited for what you’re trying to test. There are, of course, scenarios where integration tests may end up being more work to write and maintain in the long run than unit tests with mocking - use your best judgement.

5

I might move more into Integration testing yep, I agree with you

6

Hey!

I have moved into integration testing, using the nakama js client.

Any tips to avoid openHandles with jest when calling for rpcs and/or using nakama sockets to test the match handler?

Im using await/async approach, and I always disconnect the sockets at the end.

Also, a way to avoid this when running tests “Socket connection has not been established yet” which occurs randomly.