What you're about to learn

By the time you're done with this unit, you'll:

Testing Kubernetes is pretty complicated. We will try to make it easy for you, but you might want to start by reading the Development Guide.

What are the different types of tests?

In the course of developing Kubernetes, you will interact with three different test types:

Let's learn about each type of test!

Unit tests run against the smallest possible components of code, like an individual function or API calls.

Contributions with new significant functionality must come with unit tests!
Unit tests can use mock clients and servers to emulate aspects of the Kubernetes API for testing.

Integration tests make sure that components work together flawlessly as a group.

All significant features require integration tests—including kubectl commands.
Integration tests are able to test the behavior of the Kubernetes API without bringing up a whole cluster.
This makes integration tests more realistic than unit tests.

End-to-end (E2E) tests emulate an entire execution path across the entire application, from start to end.

E2E tests are the last signal to ensure end user operations match developer specifications.
Significant features should come with e2e tests.
- If you contribute a new feature without e2e tests, be prepared to explain your reasoning to your PR's reviewers.

"Developers! Developers! Developers!" — Steve Ballmer

Any contributor adding new functionality will be responsible for creating tests that validate their contribution.
Any contributor submitting a pull request will be responsible for making sure that tests run against their contribution—and pass!
SIG Testing is responsible for maintaining the test framework.

Presubmission is the phase before a pull request is created—the steps that you, the contributor, can take to maximize your PR's chance of success.

Presubmission verification is a collection of checks that give your pull request the best chance of being accepted.
Developers need to run as many verification tests as possible locally.
Learn how to run them in the Development Guide.

Pull requests need to pass all unit tests.

Pull requests also need to pass all integration tests.

If you are testing locally, you might need to install extra software.
These tests are run from your development environment with make test-integration
Read Integration Testing in Kubernetes to learn more about this type of test.

E2E tests build test binaries, spin up a test cluster, run the tests, and then tear the cluster down.

You should run tests locally or in your development environment before submitting a pull request, because it will speed up the process.

The bots that process pull requests will run tests against your code!
When the tests fail, your pull request will stall.
You will need to use the /ok-to-test command to tell the bot to run tests again.

We've covered a lot of ground in this unit, and if you want to go deeper, here is a collection of all the resources we used.