Doc: fix markups, capitalization and add 2 REVIEWING advices
I've been reading our entire documentation to see where it could
be improved. It's guide good actually. While reading I've fixed
some typos, added some capitalization to project names, mostly
trivial stuff.
What's worth reviewing is the 2 paragraphs I added to the REVIEWING
guidelines.
Change-Id: I977de335119f4ff7b9aedcfbed31c264ed531ea8
diff --git a/doc/source/write_tests.rst b/doc/source/write_tests.rst
index 4e3bfa2..aec55e9 100644
--- a/doc/source/write_tests.rst
+++ b/doc/source/write_tests.rst
@@ -6,13 +6,13 @@
This guide serves as a starting point for developers working on writing new
Tempest tests. At a high level tests in Tempest are just tests that conform to
the standard python `unit test`_ framework. But there are several aspects of
-that are unique to tempest and it's role as an integration test suite running
+that are unique to Tempest and its role as an integration test suite running
against a real cloud.
.. _unit test: https://docs.python.org/3.6/library/unittest.html
-.. note:: This guide is for writing tests in the tempest repository. While many
- parts of this guide are also applicable to tempest plugins, not all
+.. note:: This guide is for writing tests in the Tempest repository. While many
+ parts of this guide are also applicable to Tempest plugins, not all
the APIs mentioned are considered stable or recommended for use in
plugins. Please refer to :ref:`tempest_plugin` for details about
writing plugins
@@ -24,8 +24,8 @@
The base unit of testing in Tempest is the `TestCase`_ (also called the test
class). Each TestCase contains test methods which are the individual tests that
will be executed by the test runner. But, the TestCase is the smallest self
-contained unit for tests from the tempest perspective. It's also the level at
-which tempest is parallel safe. In other words, multiple TestCases can be
+contained unit for tests from the Tempest perspective. It's also the level at
+which Tempest is parallel safe. In other words, multiple TestCases can be
executed in parallel, but individual test methods in the same TestCase can not.
Also, all test methods within a TestCase are assumed to be executed serially. As
such you can use the test case to store variables that are shared between
@@ -151,7 +151,7 @@
You can also specify credentials with specific roles assigned. This is useful
for cases where there are specific RBAC requirements hard coded into an API.
The canonical example of this are swift tests which often want to test swift's
-concepts of operator and reseller_admin. An actual example from tempest on how
+concepts of operator and reseller_admin. An actual example from Tempest on how
to do this is::
class PublicObjectTest(base.BaseObjectTest):
@@ -187,7 +187,7 @@
| [$label, $role] | cls.os_roles_$label |
+-------------------+---------------------+
-By default cls.os_primary is available since it is allocated in the base tempest test
+By default cls.os_primary is available since it is allocated in the base Tempest test
class (located in tempest/test.py). If your TestCase inherits from a different
direct parent class (it'll still inherit from the BaseTestCase, just not
directly) be sure to check if that class overrides allocated credentials.
@@ -195,8 +195,8 @@
Dealing with Network Allocation
'''''''''''''''''''''''''''''''
-When neutron is enabled and a testing requires networking this isn't normally
-automatically setup when a tenant is created. Since tempest needs isolated
+When Neutron is enabled and a testing requires networking this isn't normally
+automatically setup when a tenant is created. Since Tempest needs isolated
tenants to function properly it also needs to handle network allocation. By
default the base test class will allocate a network, subnet, and router
automatically (this depends on the configured credential provider, for more