| | 4 | |
| | 5 | == Test objects == |
| | 6 | |
| | 7 | Test objects are represented by Python classes. |
| | 8 | |
| | 9 | [[BR]] |
| | 10 | '''!TestCatalog''' |
| | 11 | A container for test cases and sub-catalogs. |
| | 12 | |
| | 13 | Test catalogs are organized in a tree. Since wiki pages are instead |
| | 14 | on a flat plane, we use a naming convention to flatten the tree into |
| | 15 | page names. These are examples of wiki page names for a tree: |
| | 16 | TC --> root of the tree. This page is automatically |
| | 17 | created at plugin installation time. |
| | 18 | TC_TT0 --> test catalog at the first level. Note that 0 is |
| | 19 | the catalog ID, generated at creation time. |
| | 20 | TC_TT0_TT34 --> sample sub-catalog, with ID '34', of the catalog |
| | 21 | with ID '0' |
| | 22 | TC_TT27 --> sample other test catalog at first level, with |
| | 23 | ID '27' |
| | 24 | |
| | 25 | There is not limit to the depth of a test tree. |
| | 26 | |
| | 27 | Test cases are contained in test catalogs, and are always |
| | 28 | leaves of the tree: |
| | 29 | |
| | 30 | TC_TT0_TT34_TC65 --> sample test case, with ID '65', contained |
| | 31 | in sub-catalog '34'. |
| | 32 | Note that test case IDs are independent on |
| | 33 | test catalog IDs. |
| | 34 | [[BR]] |
| | 35 | Attributes: |
| | 36 | |
| | 37 | For the following attributes, use the dictionary assignment syntax: {{{obj['attribute_name'] = new_value}}} |
| | 38 | |
| | 39 | '''id''': A string identifier[[BR]] |
| | 40 | '''page_name''': The name of the associated Wiki page holding the title and description.[[BR]] |
| | 41 | |
| | 42 | For the following attributes, use the python object assignment syntax: {{{obj.attribute_name = new_value}}} |
| | 43 | |
| | 44 | '''title''': The title.[[BR]] |
| | 45 | '''description''': The catalog body text.[[BR]] |
| | 46 | |
| | 47 | [[BR]] |
| | 48 | '''!TestCase''' |
| | 49 | A single test case definition, usually specifying the steps |
| | 50 | required to test a particular condition, and the expected result. |
| | 51 | [[BR]] |
| | 52 | Attributes: |
| | 53 | |
| | 54 | For the following attributes, use the dictionary assignment syntax: {{{obj['attribute_name'] = new_value}}} |
| | 55 | |
| | 56 | '''id''': A string identifier[[BR]] |
| | 57 | '''page_name''': The name of the associated Wiki page holding the title and description.[[BR]] |
| | 58 | |
| | 59 | For the following attributes, use the python object assignment syntax: {{{obj.attribute_name = new_value}}} |
| | 60 | |
| | 61 | '''title''': The title.[[BR]] |
| | 62 | '''description''': The test case body text.[[BR]] |
| | 63 | |
| | 64 | [[BR]] |
| | 65 | '''!TestPlan''' |
| | 66 | A test plan represents a particular instance of test execution |
| | 67 | for a test catalog. |
| | 68 | You can create any number of test plans on any test catalog (or |
| | 69 | sub-catalog). |
| | 70 | A test plan is associated to a test catalog, and to every |
| | 71 | test case in it, with the initial state equivalent to |
| | 72 | "to be executed". |
| | 73 | The association with test cases is achieved through the |
| | 74 | TestCaseInPlan objects. |
| | 75 | |
| | 76 | For optimization purposes, a TestCaseInPlan is created in the |
| | 77 | database only as soon as its status is changed (i.e. from "to be |
| | 78 | executed" to something else). |
| | 79 | So you cannot always count on the fact that a TestCaseInPlan |
| | 80 | actually exists for every test case in a catalog, when a particular |
| | 81 | test plan has been created for it. |
| | 82 | [[BR]] |
| | 83 | Attributes: |
| | 84 | |
| | 85 | For the following attributes, use the dictionary assignment syntax: {{{obj['attribute_name'] = new_value}}} |
| | 86 | |
| | 87 | '''id''': A string identifier[[BR]] |
| | 88 | '''catid''': The string identifier of the associated test catalog[[BR]] |
| | 89 | '''page_name''': The name of the associated catalog Wiki page.[[BR]] |
| | 90 | '''name''': The test plan name[[BR]] |
| | 91 | '''author''': The creator of the test plan[[BR]] |
| | 92 | '''time''': The timestamp of the test plan creation, as a long[[BR]] |
| | 93 | |
| | 94 | [[BR]] |
| | 95 | '''!TestCaseInPlan''' |
| | 96 | This object represents a test case in a test plan. |
| | 97 | It keeps the latest test execution status (aka verdict). |
| | 98 | |
| | 99 | The status, as far as this class is concerned, can be just any |
| | 100 | string. |
| | 101 | The plugin logic, anyway, currently recognizes only three hardcoded |
| | 102 | statuses, but this can be evolved without need to modify also this |
| | 103 | class. |
| | 104 | |
| | 105 | The history of test execution status changes is instead currently |
| | 106 | kept in another table, testcasehistory, which is not backed by any |
| | 107 | python class. |
| | 108 | This is a duplication, since the 'changes' table also keeps track |
| | 109 | of status changes, so the testcasehistory table may be removed in |
| | 110 | the future. |
| | 111 | [[BR]] |
| | 112 | Attributes: |
| | 113 | |
| | 114 | For the following attributes, use the dictionary assignment syntax: {{{obj['attribute_name'] = new_value}}} |
| | 115 | |
| | 116 | '''id''': A string identifier[[BR]] |
| | 117 | '''planid''': The string identifier of the associated test plan[[BR]] |
| | 118 | '''page_name''': The name of the associated test case Wiki page.[[BR]] |
| | 119 | '''status''': The test case current status. The available default values for this field are "to_be_tested", "successful", "failed", but the USer can customize these in the trac.ini file. See [wiki:TestManagerForTracPlugin#CustomTestCaseOutcomesi.e.statesverdicts Custom Test Case Outcomes (i.e. states, verdicts)] for details.[[BR]] |
| | 120 | |
| | 121 | [[BR]] |
| | 122 | |
