-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Add an integration test for the Kubernetes Ingress controller client logic. #1889
Description
Do you want to request a feature or report a bug?
feature.
What did you do?
Make the already very awesome Traefik Ingress controller client implementation even more awesome.
What did you expect to see?
My change being covered by an integration test proving the next level in awesomeness achieved.
What did you see instead?
Being on my own with just unit tests, but nothing that tests the actual client.
Details
While we have fairly decent unit test coverage to validate our Ingress controller business logic, we are lacking integration tests for the client part (i.e., everything related to creating a client, but most importantly the functionality setting up the Informer). Unit-testing this part doesn't really make sense IMHO since the logic is highly dependent on interactions with an actual k8s API server.
I've done a bit of research how to best set up a Kubernetes system/cluster suitable for integration testing purposes (but not much more). There seem to be two viable options:
- Use the test apiserver. The nice thing is that it runs all in-process and comes with its own etcd testing copy. Note that 1.7 doesn't come with the test apiserver yet, but something similar exists in test/integration/framework. Back-porting the test apiserver to 1.7 should also be fairly trivial.
- Use Mirantis's kubeadm-dind-cluster, which brings a full cluster that only needs Docker.
AFAICS, the test apiserver would make for a more light-weight approach but might require a bit of preparation (e.g., creating a Docker image for the k8s release we're targeting). The dind approach is presumably simpler to integrate into our pre-existing docker-compose-based infrastructure but gives us things we don't really need; for instance, a multi-node setup is not strictly required to test the Informer.