openstack
/
tempest
Code Issues Proposed changes

Fixes grammatical errors in HACKING.rst 

There are a few lines in HACKING.rst that were incorrect
grammatically. This fix changes those.

Change-Id: I8173dae3cf3a3e78a504b4edd4a7c1ff5b7fb9a4
Closes-Bug: #1389603
This commit is contained in:
Mithil Arun 2014-11-05 15:58:50 +05:30
parent 6fe06450c4
commit be067ec235
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
HACKING.rst
View File

@ -36,11 +36,11 @@ by the exception and the log.
In most cases the very first issue is the most important information.
Try to avoid using ``try`` blocks in the test cases, both the ``except``
and ``finally`` block could replace the original exception,
Try to avoid using ``try`` blocks in the test cases, as both the ``except``
and ``finally`` blocks could replace the original exception,
when the additional operations leads to another exception.
Just letting an exception to propagate, is not bad idea in a test case,
Just letting an exception to propagate, is not a bad idea in a test case,
at all.
Try to avoid using any exception handling construct which can hide the errors
@ -54,10 +54,10 @@ Use of ``self.addCleanup`` is often a good way to avoid having to catch
exceptions and still ensure resources are correctly cleaned up if the
test fails part way through.
Use the ``self.assert*`` methods provided by the unit test framework
the signal failures early.
Use the ``self.assert*`` methods provided by the unit test framework.
This signals the failures early on.
Avoid using the ``self.fail`` alone, it's stack trace will signal
Avoid using the ``self.fail`` alone, its stack trace will signal
the ``self.fail`` line as the origin of the error.
Avoid constructing complex boolean expressions for assertion.
@ -69,7 +69,7 @@ for providing more information.
Most other assert method can include more information by default.
For example ``self.assertIn`` can include the whole set.
Recommended to use testtools matcher for more tricky assertion.
It is recommended to use testtools matcher for the more tricky assertions.
`[doc] <http://testtools.readthedocs.org/en/latest/for-test-authors.html#matchers>`_
You can implement your own specific matcher as well.
@ -77,8 +77,8 @@ You can implement your own specific matcher as well.
If the test case fails you can see the related logs and the information
carried by the exception (exception class, backtrack and exception info).
This and the service logs are your only guide to find the root cause of flaky
issue.
This and the service logs are your only guide to finding the root cause of flaky
issues.
Test cases are independent
--------------------------
@ -87,7 +87,7 @@ any other ``test_method`` or ``test_method`` ordering.
Test cases MAY depend on commonly initialized resources/facilities, like
credentials management, testresources and so on. These facilities, MUST be able
to work even if just one ``test_method`` selected for execution.
to work even if just one ``test_method`` is selected for execution.
Service Tagging
---------------