1,072
edits
QA/Execution/Web Testing/Docs/Automation/Testcases/ConventionsAmoTests: Difference between revisions
Jump to navigation
Jump to search
QA/Execution/Web Testing/Docs/Automation/Testcases/ConventionsAmoTests (view source)
Revision as of 01:54, 9 November 2010
, 9 November 2010→Skipping Exceptions ( aka exception to the exception )
| Line 177: | Line 177: | ||
== Skipping Exceptions ( aka exception to the exception ) == | == Skipping Exceptions ( aka exception to the exception ) == | ||
Sometimes | Sometimes a test fails because of a narrow set of conditions and a fix to the web page is not imminent. The known add-ons involved might be only one or a few. An actual example is a verification that expects add-on descriptions on on the browse and detail pages to be the same (accounting for the possibility the browse page description is truncated). The description for a particular add-on has an embedded URL which one the add-on detail page is followed by a space and not followed by space on the browse page. | ||
Because the problem is minor it’s undesirable to disable the entire test in the suite, disable the verification in the test, or dilute the verification to avoid the condition (i.e. compare only the first 25 chars of the descriptions). | Because the problem is minor it’s undesirable to disable the entire test in the suite, disable the verification in the test, or dilute the verification to avoid the condition (i.e. compare only the first 25 chars of the descriptions). To address situations similar to this, additional logic is added to to the exception handling that checks for the limited condition before generating an exception. If the limited condition is detected the normal exception message is printed to the console, otherwise the exception is generated as usual. The result is the test had the potential of finishing green despite the minor issue, without losing visibility to the exception-to-the-exception. | ||
Implementation in test cases often takes the form similar to | Implementation in test cases often takes the form similar to | ||
if conditionX: | # if conditionX then there's an exception | ||
# if conditionY then we prefer not to generate a real exception | |||
if conditionX: | |||
m1 = “this did not match that” | m1 = “this did not match that” | ||
m2 = “value found ‘%s’, expected ‘%s’ “ % (valueA, valueB) | m2 = “value found ‘%s’, expected ‘%s’ “ % (valueA, valueB) | ||
| Line 192: | Line 195: | ||
print “. skipped exception”, m1, “bug 123456”, m2 | print “. skipped exception”, m1, “bug 123456”, m2 | ||
else: | else: | ||
save_exception(m1, m2) # or raise Exception, m1+m2 | ex.save_exception(m1, m2) # or raise Exception, (m1+m2) | ||
Points to note | |||
* The word Bugzilla is included in the comment to provide a keyword for source code searches across all test cases. | |||
* The word Bugzilla is included in the comment to provide a keyword for source code searches. | |||
* The bug# appears in the comment, and more importantly in the print statement. | * The bug# appears in the comment, and more importantly in the print statement. | ||
* The information that would appear in the exception appears in the print statement | * The information that would appear in the exception appears in the print statement | ||
| Line 202: | Line 204: | ||
* conditions X and Y appear in separate statements so that logic for the exception and exception-to-the-exception is clear. | * conditions X and Y appear in separate statements so that logic for the exception and exception-to-the-exception is clear. | ||
Normally, a test case would not entirely skip add-ons because of a known condition in one element. | Normally, a test case would not entirely skip add-ons because of a known condition in one element. On the other hand, an add-on might be skipped completely if a condition affects multiple elements or verifications, and would require an exception to multiple exceptions. | ||