- From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
- Date: Fri, 24 May 2002 14:02:52 -0400
- To: www-qa@w3.org
Jack Morrison writes: >What is the order of things? I thought the current definition implied >Atomic Test, Test Case, Test Purpose, Test Assertion(s). Specs (should) contain test assertions. In order to get good ones, the spec writers should think about test cases. A test document (XML to be displayed, transformed, transmitted, etc.) may contain enough material to represent many tests. These tests may be independent of one another, which we call non-atomic, and which is probably bad. A test document should embody one test case, and that ought to be an atomic test case, or at least molecular if atomic is not possible. I could digress about real-world considerations for the test documents, but I won't (for now). Jack cites this as a test assertion: "Non-positive radius is an error condition." If that is a good example, then you won't have very many atomic tests! Right away, I see two classes of test cases: A. Any routine that produces a radius must ensure that it is numeric and positive. B. Any routine that consumes a radius parameter as input must signal an error if it is given a non-positive value. A more complete assertion of type B might be, for example: "DrawCircle() must raise an error if it is given a radius value that is numeric but non-positive." That looks like a reasonable test assertion because one can readily devise a test to call DrawCircle() with a negative number as its radius argument. Presumably, all the front matter of the test that sets up conditions under which DrawCircle can be called would not detract from the atomic nature of the test. The problems arise in geometric proportion to the number of "if" clauses needed to isolate the case being presented in the assertion. The word "or" can also cause messy situations, or it may just represent an attempt to economize on words. For example: "If the content of an attribute node is obtained from more than one operation that creates text, and if one of the text operations has an error, the attribute must not be created even if the text operation has a prescribed means of recovering and returning an empty string." Each "if" in the above sentence implies that there is another branch (maybe more than one) that are dealt with in other assertions. .................David Marston
Received on Friday, 24 May 2002 14:17:18 UTC