Changes between Version 5 and Version 6 of TestManagerForTracPluginPythonApi
- Timestamp:
- Jun 12, 2015, 11:25:02 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TestManagerForTracPluginPythonApi
v5 v6 1 1 ''' [ [wiki:TestManagerForTracPlugin Home] | [wiki:TestManagerForTracPluginChangeHistory Latest changes] | [wiki:TestManagerForTracPluginGallery Image gallery] | [http://www.youtube.com/watch?v=BIi3QMT0rT4 Video tutorial on Youtube] | [wiki:TestManagerForTracPluginQuickSetup Quick setup guide] | [http://sourceforge.net/projects/testman4trac Download] | [http://sourceforge.net/projects/testman4trac/files Source] | [wiki:TestManagerForTracPluginBugsFeatures Bugs/Feature requests] ]''' 2 2 3 = Test Manager for Trac Plugin - The Python API =3 = Test Manager for Trac Plugin - The Python API 4 4 5 5 TODO: The main API is to be described. What follows is a subset of functions recently requested by Users. 6 6 7 == Test objects ==7 == Test objects 8 8 9 9 Test objects are represented by Python classes. 10 10 11 [[BR]]12 11 '''!TestCatalog''' 13 12 A container for test cases and sub-catalogs. 14 13 15 Test catalogs are organized in a tree. Since wiki pages are instead 16 on a flat plane, we use a naming convention to flatten the tree into 14 Test catalogs are organized in a tree. Since wiki pages are instead on a flat plane, we use a naming convention to flatten the tree into 17 15 page names. These are examples of wiki page names for a tree: 18 TC --> root of the tree. This page is automatically 19 20 TC_TT0 --> test catalog at the first level. Note that 0 is 21 22 TC_TT0_TT34 --> sample sub-catalog, with ID '34', of the catalog 23 with ID '0'24 TC_TT27 --> sample other test catalog at first level, with 25 ID '27'16 17 TC --> root of the tree. This page is automatically created at plugin installation time. 18 19 TC_TT0 --> test catalog at the first level. Note that 0 is the catalog ID, generated at creation time. 20 21 TC_TT0_TT34 --> sample sub-catalog, with ID '34', of the catalog with ID '0'. 22 23 TC_TT27 --> sample other test catalog at first level, with ID '27'. 26 24 27 There is no tlimit to the depth of a test tree.25 There is no limit to the depth of a test tree. 28 26 29 Test cases are contained in test catalogs, and are always 30 leaves of the tree: 27 Test cases are contained in test catalogs, and are always leaves of the tree: 31 28 32 TC_TT0_TT34_TC65 --> sample test case, with ID '65', contained 33 in sub-catalog '34'. 34 Note that test case IDs are independent on 35 test catalog IDs. 29 TC_TT0_TT34_TC65 --> sample test case, with ID '65', contained in sub-catalog '34'. 30 Note that test case IDs are independent on test catalog IDs. 36 31 [[BR]] 37 32 '''Attributes:''' … … 49 44 [[BR]] 50 45 '''!TestCase''' 51 A single test case definition, usually specifying the steps 52 required to test a particular condition, and the expected result. 46 A single test case definition, usually specifying the steps required to test a particular condition, and the expected result. 53 47 [[BR]] 54 48 '''Attributes:''' … … 66 60 [[BR]] 67 61 '''!TestPlan''' 68 A test plan represents a particular instance of test execution 69 for a test catalog. 70 You can create any number of test plans on any test catalog (or 71 sub-catalog). 72 A test plan is associated to a test catalog, and to every 73 test case in it, with the initial state equivalent to 74 "to be executed". 75 The association with test cases is achieved through the 76 !TestCaseInPlan objects. 62 A test plan represents a particular instance of test execution for a test catalog. 63 You can create any number of test plans on any test catalog (or sub-catalog). 64 A test plan is associated to a test catalog, and to every test case in it, with the initial state equivalent to "to be executed". 65 The association with test cases is achieved through the !TestCaseInPlan objects. 77 66 78 For optimization purposes, a !TestCaseInPlan is created in the 79 database only as soon as its status is changed (i.e. from "to be 67 For optimization purposes, a !TestCaseInPlan is created in the database only as soon as its status is changed (ie from "to be 80 68 executed" to something else). 81 So you cannot always count on the fact that a !TestCaseInPlan 82 actually exists for every test case in a catalog, when a particular 83 test plan has been created for it. 69 So you cannot always count on the fact that a !TestCaseInPlan actually exists for every test case in a catalog, when a particular test plan has been created for it. 84 70 [[BR]] 85 71 '''Attributes:''' … … 99 85 It keeps the latest test execution status (aka verdict). 100 86 101 The status, as far as this class is concerned, can be just any 102 string. 103 The plugin logic, anyway, currently recognizes only three hardcoded 104 statuses, but this can be evolved without need to modify also this 105 class. 87 The status, as far as this class is concerned, can be any string. 88 The plugin logic currently recognizes three hardcoded statuses, but this can be evolved without a need to modify this class. 106 89 107 The history of test execution status changes is instead currently 108 kept in another table, testcasehistory, which is not backed by any 109 python class. 110 This is a duplication, since the 'changes' table also keeps track 111 of status changes, so the testcasehistory table may be removed in 112 the future. 90 The history of test execution status changes is instead currently kept in another table, testcasehistory, which is not backed by any 91 Python class. 92 This is a duplication, since the 'changes' table also keeps track of status changes, so the testcasehistory table may be removed in the future. 113 93 [[BR]] 114 94 '''Attributes:''' … … 121 101 '''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]] 122 102 123 [[BR]] 124 125 126 == Getting all the Tickets related to a Test Case == 103 == Getting all the Tickets related to a Test Case 127 104 128 105 '''Since: 1.4.1''' … … 134 111 From a TestCaseInPlan object, you can list the tickets opened against the test case in the specific plan. 135 112 136 {{{ 113 {{{#!python 137 114 from testmanager.model import TestCase, TestCaseInPlan 138 115 … … 148 125 This is achieved by adding two custom fields to the ticket object, named 'testcaseid' for the test case ID, and 'planid' for the test plan ID. 149 126 150 == Registering listeners to Test objects lifecycle events ==127 == Registering listeners to Test objects lifecycle events 151 128 152 129 Being based on the [wiki:TestManagerForTracPluginGenericClass Generic Persistent Class plugin], every test object supports a listener interface for components interested in test lifecycle events.
