github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add conventions

Browse Source
This commit is contained in:
Erick Fejta 2016-03-06 19:50:31 -08:00
parent fd4fee788b
commit aaa51d0bb2
2 changed files with 34 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/devel/coding-conventions.md
View File

@ -64,6 +64,7 @@ Testing conventions
- Significant features should come with integration (test/integration) and/or [end-to-end (test/e2e) tests](e2e-tests.md)
- Including new kubectl commands and major features of existing commands
- Unit tests must pass on OS X and Windows platforms - if you use Linux specific features, your test case must either be skipped on windows or compiled out (skipped is better when running Linux specific commands, compiled out is required when your code does not compile on Windows).
- See the [testing guide](testing.md) for additional testing advice.
Directory and file conventions
- Avoid package sprawl. Find an appropriate subdirectory for new packages. (See [#4851](http://issues.k8s.io/4851) for discussion.)

37
docs/devel/testing.md
View File

@ -40,8 +40,17 @@ a good idea to make sure these work as well.
## Unit tests
Unit tests should be fully hermetic and
access no resources outside the test binary.
* Unit tests should be fully hermetic
- Only access resources in the test binary.
* All packages and any significant files require unit tests.
* The preferred method of testing multiple scenarios or inputs
is [table driven testing](https://github.com/golang/go/wiki/TableDrivenTests)
- Example: [TestNamespaceAuthorization](../../test/integration/auth_test.go)
* Unit tests must pass on OS X and Windows platforms.
- Tests using linux-specific features must be skipped or compiled out.
- Skipped is better, compiled out is required when it won't compile.
* Concurrent unit test runs must pass.
* See [coding conventions](coding-conventions.md).
### Run all unit tests
@ -123,8 +132,17 @@ See `go help test` and `go help testflag` for additional info.
## Integration tests
Integration tests should only access other resources on the local machine,
most commonly etcd or a kubernetes/docker binary.
* Integration tests should only access other resources on the local machine
- Most commonly etcd or a service listening on localhost.
* All significant features require integration tests.
- This includes kubectl commands
* The preferred method of testing multiple scenarios or inputs
is [table driven testing](https://github.com/golang/go/wiki/TableDrivenTests)
- Example: [TestNamespaceAuthorization](../../test/integration/auth_test.go)
* Integration tests must run in parallel
- Each test should create its own master, httpserver and config.
- Example: [TestPodUpdateActiveDeadlineSeconds](../../test/integration/pods.go)
* See [coding conventions](coding-conventions.md).
### Install etcd dependency
@ -156,6 +174,17 @@ hack/test-integration.sh # Run all integration tests.
## End-to-End tests
* e2e tests build kubernetes and deploy a cluster of nodes.
- Generally on a specific cloud provider.
* Access gcr.io images
* Access a specific, non-latest image tag (unless testing pulling).
* Tests may not flake due to intermittent issues.
* Use ginko to desribe steps.
- See [should run a job to completion when tasks succeed](../../test/e2e/job.go)
* Use [NewDefaultFramework](../../test/e2e/framework.go)
- Contains clients, namespace and auto resource cleanup
* See [coding conventions](coding-conventions.md).
### e2e test philosophy
In general passing unit and integration tests should provide sufficient