This directory contains tests and testing docs for Elafros:

• Unit tests currently reside in the codebase alongside the code they test
• Conformance tests in /test/conformance
• End-to-end tests in /test/e2e

If you want to add more tests, see adding_tests.md.

Use bazel:

bazel test //pkg/... --test_output=errors

Or go test:

go test -v ./pkg/...

To run the conformance tests, you need to have a running environment that meets the conformance test environment requirements.

Since these tests are fairly slow (~1 minute), running them with logging enabled is recommended.

To run the conformance tests against the current cluster in ~/.kube/config use go test with test caching disabled and the environment specified in your environment variables:

go test -v -count=1 ./test/conformance

You can use test flags to control the environment your tests run against, i.e. override your environment variables:

go test -v -count=1 ./test/conformance --kubeconfig ~/special/kubeconfig --cluster myspecialcluster --dockerrepo myspecialdockerrepo

If you are running against an environment with no loadbalancer for the ingress, at the moment your only option is to use a domain which will resolve to the IP of the running node (see #609):

go test -v -count=1 ./test/conformance --resolvabledomain

These tests require:

1. A running Elafros cluster.
2. The namespace pizzaplanet to exist in the cluster: kubectl create namespace pizzaplanet
3. A docker repo contianing the conformance test images

The configuration for the images used for the existing conformance tests lives in test_images_node. See the section about test images for details about building and adding new ones.

To run the conformance tests with bazel you must:

• Provide a kubeconfig file. This file must be a data dependency of the test in BUILD.bazel. By default BUILD.bazel is configured to use test/conformance/kubeconfig.
• Provide a docker repo from which the built images will be pulled. This is done via the --dockerrepo argument.

The bazel execution environment will not contain your environment variables, so you must explicitly specify them with command line args.

To run the tests with bazel (assuming you have populated ./kubeconfig and your DOCKER_REPO_OVERRIDE is configured to the location where you have pushed the conformance test images):

bazel test //test/... --test_arg=--dockerrepo=$DOCKER_REPO_OVERRIDE --test_arg=--kubeconfig=./kubeconfig

The e2e tests have almost the exact same requirements and specs as the conformance tests, but they will be enumerated for clarity.

To run the e2e tests, you need to have a running environment that meets the e2e test environment requirements.

To run the e2e tests against the current cluster in ~/.kube/config using go test using the environment specified in your environment variables:

Since these tests are fairly slow, running them with logging enabled is recommended. Do so by passing the -v flag to go test like so:

go test -v ./test/e2e

You can use test flags to control the environment your tests run against, i.e. override your environment variables:

go test -v ./test/e2e --kubeconfig ~/special/kubeconfig --cluster myspecialcluster --dockerrepo myspecialdockerrepo

If you are running against an environment with no loadbalancer for the ingress, at the moment your only option is to use a domain which will resolve to the IP of the running node (see #609):

go test -v ./test/e2e --resolvabledomain

These tests require:

1. A running Elafros cluster.
2. The namespace noodleburg to exist in the cluster: kubectl create namespace noodleburg
3. A docker repo containing the e2e test images

The configuration for the images used for the existing e2e tests lives in test_images_node. See the section about test images for details about building and adding new ones.

To run the e2e tests with bazel you must:

• Provide a kubeconfig file. This file must be a data dependency of the test in BUILD.bazel. By default BUILD.bazel is configured to use test/e2e/kubeconfig.
• Provide a docker repo from which the built images will be pulled. This is done via the --dockerrepo argument.

The bazel execution environment will not contain your environment variables, so you must explicitly specify them with command line args.

To run the tests with bazel (assuming you have populated ./kubeconfig and your DOCKER_REPO_OVERRIDE is configured to the location where you have pushed the e2e test images):

bazel test //test/... --test_arg=--dockerrepo=$DOCKER_REPO_OVERRIDE --test_arg=--kubeconfig=./kubeconfig

The upload-test-images.sh script can be used to build and push the test images used by the conformance and e2e tests. It requires:

• DOCKER_REPO_OVERRIDE to be set
• You to be authenticated with your DOCKER_REPO_OVERRIDE
• docker to be installed

To run the script:

./test/upload-test-images.sh /path/containing/test/images

The path containing test images is any directory whose subdirectories contain the Dockerfile and any required files to build Docker images (e.g., ./test/e2e/test_images_node).

New test images should be placed in their own subdirectories. Be sure to to include a Dockerfile for building and running the test image.

The new test images will also need to be uploaded to the e2e tests Docker repo. You will need one of the owners found in /test/OWNERS to do this.

These flags are useful for running against an existing cluster, making use of your existing environment setup.

Tests importing github.com/elafros/elafros/test recognize these flags:

• --kubeconfig
• --cluster
• --dockerrepo
• --resolvabledomain

By default the tests will use the kubeconfig file at ~/.kube/config. You can specify a different config file with the argument --kubeconfig.

To run the tests with a non-default kubeconfig file:

go test ./test/conformance --kubeconfig /my/path/kubeconfig

go test ./test/e2e --kubeconfig /my/path/kubeconfig

The --cluster argument lets you use a different cluster than your specified kubeconfig's active context. This will default to the value of your K8S_CLUSTER_OVERRIDE environment variable if not specified.

go test ./test/conformance --cluster your-cluster-name

go test ./test/e2e --cluster your-cluster-name

The current cluster names can be obtained by running:

kubectl config get-clusters

The --dockerrepo argument lets you specify the docker repo from which images used by your tests should be pulled. This will default to the value of your DOCKER_REPO_OVERRIDE environment variable if not specified.

go test ./test/conformance --dockerrepo gcr.myhappyproject

go test ./test/e2e --dockerrepo gcr.myhappyproject

If you set up your cluster using the getting started docs, Routes created in the test will use the domain demo-domain.com, unless the route has label app=prod in which case they will use the domain prod-domain.com. Since these domains will not be resolvable to deployments in your test cluster, in order to make a request against the endpoint, the test use the IP assigned to the istio *-ela-ingress and spoof the Host in the header.

If you have configured your cluster to use a resolvable domain, you can use the --resolvabledomain flag to indicate that the test should make requests directly against Route.Status.Domain and does not need to spoof the Host.