diff --git a/HACKING.rst b/HACKING.rst index eafa81b961..1db1e26042 100644 --- a/HACKING.rst +++ b/HACKING.rst @@ -1,3 +1,7 @@ +Tempest Coding Guide +==================== + + Test Data/Configuration ----------------------- - Assume nothing about existing test data diff --git a/doc/source/HACKING.rst b/doc/source/HACKING.rst new file mode 120000 index 0000000000..a2f06b723d --- /dev/null +++ b/doc/source/HACKING.rst @@ -0,0 +1 @@ +../../HACKING.rst \ No newline at end of file diff --git a/doc/source/index.rst b/doc/source/index.rst index 1ca7344304..e8fdf2c10f 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -3,9 +3,9 @@ You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. -=================================== +======================= Tempest Testing Project -=================================== +======================= Contents: @@ -13,11 +13,11 @@ Contents: :maxdepth: 2 overview + HACKING - -------------------------------- +------------ Field Guides -------------------------------- +------------ Tempest contains tests of many different types, the field guides attempt to explain these in a way that makes it easy to understand where your test contributions should go. diff --git a/tempest/api/README.rst b/tempest/api/README.rst index cf0aac7afb..617fda4bed 100644 --- a/tempest/api/README.rst +++ b/tempest/api/README.rst @@ -1,9 +1,9 @@ Tempest Guide to API tests -======== +========================== What are these tests? --------- +--------------------- One of Tempest's prime function is to ensure that your OpenStack cloud works with the OpenStack API as documented. The current largest @@ -21,7 +21,7 @@ spinning up a server, image, etc, then opperating on it. Why are these tests in tempest? --------- +------------------------------- This is one of the core missions for the Tempest project, and where it started. Many people use this bit of function in Tempest to ensure @@ -34,7 +34,7 @@ place to keep things. Scope of these tests --------- +-------------------- API tests should always use the Tempest implementation of the OpenStack API, as we want to ensure that bugs aren't hidden by the diff --git a/tempest/cli/README.rst b/tempest/cli/README.rst index 4742d4a3e9..76b05a34a9 100644 --- a/tempest/cli/README.rst +++ b/tempest/cli/README.rst @@ -1,16 +1,16 @@ Tempest Guide to CLI tests -======== +========================== What are these tests? ---------- +--------------------- The cli tests test the various OpenStack command line interface tools to ensure that they minimally function. The current scope is read only operations on a cloud that are hard to test via unit tests. Why are these tests in tempest? ---------- +------------------------------- These tests exist here because it is extremely difficult to build a functional enough environment in the python-*client unit tests to provide this kind of testing. Because we already put up a cloud in the @@ -20,14 +20,14 @@ would split review time. Scope of these tests ---------- +-------------------- This should stay limited to the scope of testing the cli. Functional testing of the cloud should be elsewhere, this is about exercising the cli code. Example of a good test ---------- +---------------------- Tests should be isolated to a single command in one of the python clients. diff --git a/tempest/scenario/README.rst b/tempest/scenario/README.rst index c5fa0d358e..98b74e436a 100644 --- a/tempest/scenario/README.rst +++ b/tempest/scenario/README.rst @@ -1,9 +1,9 @@ Tempest Guide to Scenario tests -======== +=============================== What are these tests? --------- +--------------------- Scenario tests are "through path" tests of OpenStack function. Complicated setups where one part might depend on completion @@ -17,13 +17,13 @@ from that snapshot. Why are these tests in tempest? --------- +------------------------------- This is one of tempests core purposes, testing the integration between projects. Scope of these tests --------- +-------------------- Scenario tests should always test at least 2 services in interaction. They should use the official python client libraries for OpenStack, as they provide a more realistic approach in how people @@ -34,7 +34,7 @@ services they exercise. Example of a good test --------- +---------------------- While we are looking for interaction of 2 or more services, be specific in your interactions. A giant "this is my data center" smoke test is hard to debug when it goes wrong. diff --git a/tempest/stress/README.rst b/tempest/stress/README.rst index 2fcdf2ea84..661763cce9 100644 --- a/tempest/stress/README.rst +++ b/tempest/stress/README.rst @@ -1,5 +1,5 @@ Tempest Field Guide to Stress Tests -====================================================== +=================================== Nova is a distributed, asynchronous system that is prone to race condition bugs. These bugs will not be easily found during @@ -9,7 +9,7 @@ in a more controlled environment. Environment ------------- +----------- This particular framework assumes your working Nova cluster understands Nova API 2.0. The stress tests can read the logs from the cluster. To enable this you have to provide the hostname to call 'nova-manage' and diff --git a/tempest/whitebox/README.rst b/tempest/whitebox/README.rst index dabf758aa3..0e454211ab 100644 --- a/tempest/whitebox/README.rst +++ b/tempest/whitebox/README.rst @@ -1,9 +1,9 @@ Tempest Guide to Whitebox tests -======== +=============================== What are these tests? --------- +--------------------- When you hit the OpenStack API, this causes internal state changes in the system. This might be database transitions, vm modifications, @@ -20,7 +20,7 @@ be useful for validating Tempest internals. Why are these tests in tempest? --------- +------------------------------- Especially when it comes to something like VM state changing, which is a coordination of numerous running daemons, and a functioning VM, it's @@ -28,7 +28,7 @@ very difficult to get a realistic test like this in unit tests. Scope of these tests --------- +-------------------- White box tests should be limitted to tests where black box testing (using the OpenStack API to verify results) isn't sufficient. @@ -40,7 +40,7 @@ internals changes in OpenStack projects. Example of a good test --------- +---------------------- Pushing VMs through a series of state transitions, and ensuring along the way the database state transitions match what's expected.