End to End test

[markmandel]

Write a end to end test - possibly, using make and kubectl, or maybe use code - what is the best option?

• installation
• Creating a GameServer
• Connecting

Will likely need to both check that a connection works with the go sample (edit to send a message via a flag, rather than stdin), but also will need to check the C++ sdk works as well.

I din't think there are any e2e integration test libraries that exist for Kubernetes platforms - but do have a look first. May be worth looking at how Kubernetes itself does it.

[addisonbair]

I am new to this project and haven't yet stood up the development environment yet, but it appears that Kubernetes itself uses Ginkgo, Gomega and the Kubernetes API itself for much of the end-to-end testing of a particular release.

https://github.com/kubernetes/kubernetes/tree/master/test/e2e

Here's a simpler example from the Prometheus Operator project:

https://github.com/coreos/prometheus-operator/tree/master/test/e2e

[cyriltovena]

Should I start by some simple e2e go test and may be bring this later into an image to support in-cluster config ?

I quite like the prom-operator example.

[markmandel]

The other option is using the Helm test tooling? Or maybe there is a combo option?

Or if I follow - you're saying, start with a simple binary we can run and point at a cluster, and then move forward from there? That would make sense (assuming that's what you are suggesting)

[cyriltovena]

yes, I want to add the helm integration after, using a container.

[markmandel]

Sounds like a good approach to me!

[cyriltovena]

Gameservers:

• I can create a ready gameserver
• I can talk to the a gameserver via its external IP.
• The gameserver should become unhealthy on crash or without answering healthcheck (fake gameserver)*
• The gameserver becomes deleted on shutdown.
• I can add a port to a gameserver. (might reschedule)
• I can list gameservers.
• I can read the gameserver metadata, change it via k8s api and read it back from sdk to compare*

Fleets ?

• I can create an empty fleet.
• I can scale up a fleet.
• I can scale down a fleet to only allocated gameservers.
• I can update a fleet image and only replace unallocated gameservers.
• When a gameserver ends, it should become allocatable.*

Allocations ?

• I can allocate from a fleet if there is free gameserver.
• I can't allocate if a fleet is fully used.
• I can pass metadatas at allocation time and read it from the gamserver.*

PortAllocation ?

• I should be able to dynamically allocate multiple port if enough within range.(is it too much?)
• I should be able to statically allocates one or more ports.
• I should receive an error when there is no ports available.

* we could add more debug command to the udp go example (returns json metadata,fake a crash, stop healthchecking)

This would be an ideal e2e, but that's seems like a lot should we prioritize ?

[markmandel]

Got another one for you - if health checking is disabled, then the game server shouldn't be marked as unhealthy if no health pings are sent (just found this as a bug, and it's only going to get covered by e2e test)

But yes - we should prioritise, and we can work through them slowly each as a separate PR. Also happy to defer to your opinion on the order.

[markmandel]

Just updated this with what I completed on e2e tests.

[thisisnotapril]

Repo health check - should we keep this issue open?

[markmandel]

There are still a few left on the list (I cleaned things up a bit above) that would be good to have I think.

[markmandel]

I think this is actually good to close now. If anyone disagrees, please let me know, otherwise I'll close this next Monday.

[markmandel]

Closing!