diff options
| author | k8s-ci-robot <k8s-ci-robot@users.noreply.github.com> | 2018-07-23 14:46:39 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-07-23 14:46:39 -0700 |
| commit | 2d2feabc33402ce4c2dacbef6830198fd5ba13a3 (patch) | |
| tree | 790bc38c32c97e11380839b589b4bf82d2a59f42 /contributors/guide | |
| parent | 3938ea9530e4f903747d2609f37777c8171a9b2e (diff) | |
| parent | a08ccca6189d54ba05e4e2c39e9c7a228aa56687 (diff) | |
Merge pull request #1867 from brahmaroutu/conformance
Adding Conformance Guidelines document.
Diffstat (limited to 'contributors/guide')
| -rw-r--r-- | contributors/guide/README.md | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/contributors/guide/README.md b/contributors/guide/README.md index 7ab0e239..bee0885a 100644 --- a/contributors/guide/README.md +++ b/contributors/guide/README.md @@ -183,11 +183,12 @@ Testing is the responsibility of all contributors and is in part owned by all si The main testing overview document is [here](/contributors/devel/testing.md). -There are three types of tests in kubernetes. The location of the test code varies with type, as do the specifics of the environment needed to successfully run the test: +There are multiple types of tests in kubernetes. The location of the test code varies with type, as do the specifics of the environment needed to successfully run the test: * Unit: These confirm that a particular function behaves as intended. Golang includes a native ability for unit testing via the [testing](https://golang.org/pkg/testing/) package. Unit test source code can be found adjacent to the corresponding source code within a given package. For example: functions defined in [kubernetes/cmd/kubeadm/app/util/version.go](https://git.k8s.io/kubernetes/cmd/kubeadm/app/util/version.go) will have unit tests in [kubernetes/cmd/kubeadm/app/util/version_test.go](https://git.k8s.io/kubernetes/cmd/kubeadm/app/util/version_test.go). These are easily run locally by any developer on any OS. * Integration: These tests cover interactions of package components or interactions between kubernetes components and some other non-kubernetes system resource (eg: etcd). An example would be testing whether a piece of code can correctly store data to or retrieve data from etcd. Integration tests are stored in [kubernetes/test/integration/](https://git.k8s.io/kubernetes/test/integration). Running these can require the developer set up additional functionality on their development system. * End-to-end ("e2e"): These are broad tests of overall kubernetes system behavior and coherence. These are more complicated as they require a functional kubernetes cluster built from the sources to be tested. A separate document [here](/contributors/devel/e2e-tests.md) details e2e testing and test cases themselves can be found in [kubernetes/test/e2e/](https://git.k8s.io/kubernetes/test/e2e). +* Conformance: These are a set of testcases, currently a subset of the integration/e2e tests, that the Architecture SIG has approved to define the core set of interoperable features that all Kubernetes deployments must support. For more information on Conformance tests please see the [Conformance Testing](/contributors/devel/conformance-tests.md) Document. Continuous integration will run these tests either as pre-submits on PRs, post-submits against master/release branches, or both. The results appear on [testgrid](https://testgrid.k8s.io). |
