test

README

Tests

To run tests:

# Land the latest code
ko apply -f ./config/

# Run unit tests
go test ./...

# Run integration tests (against your current kube cluster)
go test -v -count=1 -tags=e2e -timeout=20m ./test

Unit tests

Unit tests live side by side with the code they are testing and can be run with:

go test ./...

By default go test will not run the end to end tests, which need -tags=e2e to be enabled.

End to end tests

Setup

Environment variables used by end to end tests:

• KO_DOCKER_REPO - Set this to an image registry your tests can push images to

Running

End to end tests live in this directory. To run these tests, you must provide go with -tags=e2e. By default the tests run against your current kubeconfig context, but you can change that and other settings with the flags. Run e2e tests with:

go test -v -count=1 -tags=e2e -timeout=20m ./test
go test -v -count=1 -tags=e2e -timeout=20m ./test --kubeconfig ~/special/kubeconfig --cluster myspecialcluster

You can also use all flags defined in knative/pkg/test.

Flags

• By default the e2e tests run against the current cluster in ~/.kube/config using the environment specified in your environment variables.
• Since these tests are fairly slow, running them with logging enabled is recommended (-v).
• Using --logverbose will show the verbose log output from test as well as from k8s libraries.
• Using -count=1 is the idiomatic way to disable test caching.
• The e2e tests take a long time to run, so a value like -timeout=20m can be useful depending on what you're running.

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

go test -v -tags=e2e -count=1 ./test --kubeconfig ~/special/kubeconfig --cluster myspecialcluster

Tests importing github.com/tektoncd/triggers/test recognize the flags added by knative/pkg/test.

Running specific test cases

To run all the test cases with their names starting with the same letters, e.g. EventListener, use the -run flag with go test:

go test -v -tags=e2e -count=1 ./test -run ^TestEventListener

Running YAML tests

To run the YAML e2e tests, run the following command:

./test/e2e-tests-yaml.sh

Adding integration tests

In the test dir you will find several libraries in the test package you can use in your tests.

This library exists partially in this directory and partially in knative/pkg/test.

The libs in this dir can:

• Setup tests
• Poll resources
• Generate random names

All integration tests must be marked with the e2e build constraint so that go test ./... can be used to run only the unit tests, i.e.:

// +build e2e

Setup tests

The setup function in init_tests.go will initialize client objects, create a new unique Namespace for the test, and initialize anything needed globally by the tests (i.e. logs and metrics).

clients, namespace := setup(t)

The clients struct contains initialized clients for accessing:

• Kubernetes resources
• Pipelines resources
• Triggers resources

See init_test.go and clients.go for more information.

Poll resources

After creating, updating, or deleting kubernetes resources, you will need to wait for the system to realize these changes. You can use polling methods to check the resources reach the desired state.

The WaitFor* functions use the Kubernetes wait package. For polling they use PollImmediate with a ConditionFunc callback function, which returns a bool to indicate if the polling should stop and an error to indicate if there was an error.

See wait.go for more information.

Generate random names

You can use the names package from the Tekton Pipeline project to append a random string, so that your tests can use unique names each time they run.

import "github.com/tektoncd/pipeline/pkg/names"

namespace := names.SimpleNameGenerator.RestrictLengthWithRandomSuffix("arrakis")

Running presubmit integration tests

The presubmit integration tests entrypoint will run:

• The e2e tests

When run using Prow, integration tests will try to get a new cluster using boskos, which only the tektoncd/plumbing OWNERS have access to.

Documentation

Index

• func CollectPodLogsWithLabel(c kubernetes.Interface, namespace, LabelSelector string) (string, error)
• func WaitFor(waitFunc wait.ConditionFunc) error
• type Clients
  • func SeedTestResources(t *testing.T, ctx context.Context, r TestResources) Clients
• type TestAssets
• type TestResources
  • func GetTestResourcesFromClients(c Clients) (*TestResources, error)

Functions

func CollectPodLogsWithLabel

func CollectPodLogsWithLabel(c kubernetes.Interface, namespace, LabelSelector string) (string, error)

CollectPodLogsWithLabel will get the logs of all the Pods given a LabelSelector

func WaitFor

func WaitFor(waitFunc wait.ConditionFunc) error

WaitFor waits for the specified ConditionFunc every internal until the timeout.

Types

type Clients

type Clients struct {
	Kube     *fakekubeclientset.Clientset
	Triggers *faketriggersclientset.Clientset
	Pipeline *fakepipelineclientset.Clientset
}

Clients holds references to clients which are useful for reconciler tests.

func SeedTestResources

func SeedTestResources(t *testing.T, ctx context.Context, r TestResources) Clients

SeedTestResources returns Clients populated with the given TestResources

type TestAssets

type TestAssets struct {
	Controller *controller.Impl
	Clients    Clients
}

TestAssets holds references to the controller and clients.

type TestResources

type TestResources struct {
	Namespaces     []*corev1.Namespace
	EventListeners []*v1alpha1.EventListener
	Deployments    []*appsv1.Deployment
	Services       []*corev1.Service
}

TestResources represents the desired state of the system (i.e. existing resources) to seed controllers with.

func GetTestResourcesFromClients

func GetTestResourcesFromClients(c Clients) (*TestResources, error)

GetTestResourcesFromClients returns the TestResources in the Clients provided Precondition: all Namespaces used in TestResources must be listed in TestResources.Namespaces