test

package
v0.17.3 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Aug 31, 2020 License: Apache-2.0 Imports: 5 Imported by: 1

README

Test

This directory contains tests and testing docs for Knative Eventing.

Running tests with scripts

Presubmit tests

presubmit-tests.sh is the entry point for the tests before code submission.

You can run it simply with:

test/presubmit-tests.sh

By default, this script will run build tests, unit tests and integration tests. If you only want to run one type of tests, you can run this script with corresponding flags like below:

test/presubmit-tests.sh --build-tests
test/presubmit-tests.sh --unit-tests
test/presubmit-tests.sh --integration-tests

Note that if the tests you are running include integration tests, it will create a new GKE cluster in project $PROJECT_ID, start Knative Serving and Eventing system, upload test images to $KO_DOCKER_REPO, and run all e2e-*tests.sh scripts under test. After the tests finish, it will delete the cluster.

E2E tests

e2e-tests.sh is the entry point for running all e2e tests.

You can run it simply with:

test/e2e-tests.sh

By default, it will create a new GKE cluster in project $PROJECT_ID, start Knative Serving and Eventing system, upload test images to $KO_DOCKER_REPO, and run the end-to-end tests. After the tests finishes, it will delete the cluster.

If you have already created your own Kubernetes cluster but haven't installed Knative, you can run with test/e2e-tests.sh --run-tests.

If you have set up a running environment that meets the e2e test environment requirements, you can run with test/e2e-tests.sh --run-tests --skip-knative-setup.

Running tests with go test command

Running unit tests

You can also use go test command to run unit tests:

go test -v ./pkg/...

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

Running end-to-end tests

To run the e2e tests with go test command, you need to have a running environment that meets the e2e test environment requirements, and you need to specify the build tag e2e.

If you are using a private registry that will require authentication then you'll need to create a Secret in your default Namespace called kn-eventing-test-pull-secret with the Docker login credentials. This Secret will then be copied into any new Namespace that is created by the testing infrastructure, and linked to any ServiceAccount created as a imagePullSecret. Note: some tests will use the knative-eventing-injection label to automatically create new ServiceAccounts in some Namespaces, this feature does not yet support private registries. See https://github.com/knative/eventing/issues/1862 for status of this issue.

go test -v -tags=e2e -count=1 ./test/e2e

By default, tests run against images with the latest tag. To override this bevavior you can specify a different tag through -tag:

go test -v -tags=e2e -count=1 ./test/e2e -tag e2e
One test case

To run one e2e test case, e.g. TestSingleBinaryEventForChannel, use the -run flag with go test:

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

Environment requirements

There's couple of things you need to install before running e2e tests locally.

  1. A running Knative cluster
  2. A docker repo containing the test images

Test images

Building the test images

Note: this is only required when you run e2e tests locally with go test commands. Running tests through e2e-tests.sh will publish the images automatically.

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

To run the script for all end to end test images:

./test/upload-test-images.sh

For images deployed in GCR, a docker tag is mandatory to avoid issues with using latest tag:

./test/upload-test-images.sh e2e
Adding new test images

New test images should be placed in ./test/test_images. For each image create a new sub-folder and include a Go file that will be an entry point to the application. This Go file should use the package main and include the function main(). It is a good practice to include a readme file as well. When uploading test images, ko will build an image from this folder.

Flags

Flags are similar to those in Knative Serving.

Documentation

Index

Constants

View Source
const (
	ChannelUsage = "The names of the channel type metas, separated by comma. " +
		"Example: \"messaging.knative.dev/v1alpha1:InMemoryChannel," +
		"messaging.cloud.google.com/v1alpha1:Channel,messaging.knative.dev/v1alpha1:KafkaChannel\"."
	BrokerUsage = "Which brokerclass to test, requires the proper Broker " +
		"implementation to have been installed, and only one value. brokerclass " +
		"must be (for now) 'MTChannelBasedBroker'."
	SourceUsage = "The names of the source type metas, separated by comma. " +
		"Example: \"sources.knative.dev/v1alpha1:ApiServerSource," +
		"sources.knative.dev/v1alpha1:PingSource\"."
	BrokerNameUsage = "When testing a pre-existing broker, specify the Broker name so the conformance tests " +
		"won't create their own."
	BrokerNamespaceUsage = "When testing a pre-existing broker, this variable specifies the namespace the broker can be found in."
)

Variables

EventingFlags holds the command line flags specific to knative/eventing.

Functions

func InitializeEventingFlags added in v0.9.0

func InitializeEventingFlags()

InitializeEventingFlags registers flags used by e2e tests, calling flag.Parse() here would fail in go1.13+, see https://github.com/knative/test-infra/issues/1329 for details

Types

This section is empty.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL