Changes between Version 15 and Version 16 of TestManagerForTracPluginApi


Ignore:
Timestamp:
Jan 20, 2011 5:52:56 PM (3 years ago)
Author:
seccanj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TestManagerForTracPluginApi

    v15 v16  
    22 
    33[[BR]] 
    4 The [wiki:TestManagerForTracPlugin TestManager plugin] can be used programmatically to create and manage Test Catalogs, Test Cases and Test Plans, and to set the test execution verdicts of Test Cases in a plan. 
     4The [wiki:TestManagerForTracPlugin TestManager plugin] can be used programmatically to create and manage Test Catalogs, Test Cases and Test Plans, and to set the test execution outcomes of the Test Cases in a plan. 
    55 
    6 There are two main APIs available: 
     6There are three main APIs available: 
    77 
    8  * A RESTful API, allowing you to remotely control your test artifacts by means of simple HTTP GET requests,  
    9  * A Python API, allowing for a fine-grained control over any artifact, managing their life-cycle, listening to events, reacting to status changes and workflow transitions. 
     8 * An [wiki:TestManagerForTracPluginRPCApi '''XML-RPC''' API], allowing you to remotely control your test artifacts using a standard XML-RPC protocol. For example, using the Python {{{xmlrpclib}}} library, you can get test object properties, create objects and so on with as few as two lines of code.  
     9 * An [wiki:TestManagerForTracPluginRestfulApi '''HTTP RESTful''' API], allowing you to remotely control your test artifacts by means of simple HTTP GET requests,  
     10 * A plain [wiki:TestManagerForTracPluginPythonApi '''Python''' API], allowing for components running in the Trac environment to have a fine-grained control over any artifact, managing their life-cycle, listening to events, reacting to status changes and workflow transitions. 
    1011 
    11 [[BR]] 
    12 [[BR]] 
    13 = The RESTful API = 
    14  
    15 In the following, because of the spam filter not allowing more than a few URLs in a page, I have replaced: 
    16  
    17 {{{ 
    18 http://yourserver/yourproject 
    19 }}} 
    20  
    21 with: 
    22  
    23 {{{ 
    24 <yourserver/yourproject> 
    25 }}} 
    26  
    27 == Working with Test Catalogs and Test Cases == 
    28  
    29 You can create test catalogs and cases programmatically by means of the following http requests. 
    30  
    31  
    32 === Create a root test catalog === 
    33  
    34 Get the following URL: 
    35 {{{ 
    36 <yourserver/yourproject>/testcreate?type=catalog&path=TC&title=My%20new%20catalog 
    37 }}} 
    38 this will assign a unique ID (the number 0 in the URL below) to the new catalog, create the corresponding Wiki page and redirect to it. You may discard the response if you don't need to know the catalog ID (last number in the URL): 
    39  
    40 {{{ 
    41 <yourserver/yourproject>/wiki/TC_TT0 
    42 }}} 
    43  
    44 === Create a sub-catalog === 
    45  
    46 Get the wollowing URL, where "path" is the name of the parent catalog. 
    47  
    48 <yourserver/yourproject>/testcreate?type=catalog&path=TC_TT0&title=My%20sub%20catalog 
    49 this will assign a unique ID (the number 1 in the URL below) to the new catalog, create the corresponding Wiki page and redirect to it. You may discard the response if you don't need to know the catalog ID (last number in the URL): 
    50  
    51 {{{ 
    52 <yourserver/yourproject>/wiki/TC_TT0_TT1 
    53 }}} 
    54  
    55 === Create a Test Case === 
    56  
    57 Get the following URL, where "path" is the name of the parent (sub-)catalog. 
    58  
    59 {{{ 
    60 <yourserver/yourproject>/testcreate?type=testcase&path=TC_TT0_TT1&title=My%20new%20Test%20Case 
    61 }}} 
    62  
    63 this will assign a unique ID (the number 0 in the URL below) to the new test case, create the corresponding Wiki page and redirect to it. You may discard the response if you don't need to know the test case ID (last number in the URL): 
    64  
    65 {{{ 
    66 <yourserver/yourproject>/wiki/TC_TT0_TT1_TC0 
    67 }}} 
    68  
    69  
    70 == Working with Test Plans and setting the status of a Test Case == 
    71  
    72 You can also create a new Test Plan (e.g. for each nightly build) programmatically as follows. 
    73  
    74  
    75 === Create a Test Plan from a specific catalog === 
    76  
    77 Get the following URL, where "path" is the name of the (sub-)catalog to create the test plan against. 
    78  
    79 {{{ 
    80 <yourserver/yourproject>/testcreate?type=testplan&path=TC_TT0&title=Test%20Plan%20for%2020100818 
    81 }}} 
    82  
    83 this will assign a unique ID (the number 1 in the URL below) to the new test plan and redirect to displaying the Test Plan: You may discard the response if you don't need to know the plan ID (planid parameter in the URL): 
    84  
    85 {{{ 
    86 <yourserver/yourproject>/wiki/TC_TT0?planid=1 
    87 }}} 
    88  
    89 The Test Plan will contain all of the test cases in the specified catalog, with a status of "Untested". 
    90  
    91 Note: As you can notice, you can always pass from a test catalog to one of its test plans by adding the "planid=<plan id>" parameter to the test catalog URL. The same also stands for test cases. You can pass to a test case in a particular plan by adding the planid parameter to its URL. 
    92  
    93  
    94  
    95 === Set a Test Case execution verdict, in the context of a Test Plan === 
    96  
    97 Then, you can set the verdict for any test case in the plan, by means of the following. 
    98  
    99 Get the following URL, where "id" is the Test Case ID and planid is the Test Plan ID: 
    100  
    101 {{{ 
    102 <yourserver/yourproject>/teststatusupdate?id=5&planid=1&status=SUCCESSFUL 
    103 }}} 
    104  
    105 The supported statuses are currently: 
    106  
    107  * TO_BE_TESTED 
    108  * SUCCESSFUL 
    109  * FAILED 
    110  
    111  
    112 == Change a [custom] property of any test object == 
    113  
    114 Any property, either standard or custom, of any test object can be set programmatically through the RESTful API. 
    115  
    116 A test object is identified by its realm (i.e. type) and its key (i.e. in most cases the ID, for test cases in the context of a plan, also the plan ID is required). 
    117  
    118 The realms that identify the test objects are the following: 
    119  
    120  * Test Catalog: testcatalog 
    121  * Test Case: testcase 
    122  * Test Case in the context of a plan (i.e. with a status): testcaseinplan 
    123  * Test Plan: testplan 
    124  
    125 The realm must be provided to the property update service through the "realm" parameter. 
    126  
    127 The corresponding key properties, needed to identify any particular object, are: 
    128  
    129  * Test Catalog: id 
    130  * Test Case: id 
    131  * Test Case in the context of a plan (i.e. with a status): id, planid 
    132  * Test Plan: id 
    133  
    134 The key properties are provided to the property update service through the "key" parameter, in the form of a dictionary. 
    135  
    136 The next things to pass to the service are the name of the property to modify and the new value. Guess what... you use the "name" and "value" parameters, respectively. 
    137  
    138 For example, to change a Test Case - with ID 5 - custom property "platform" (which has been previously added to the test case type in the trac.ini file) to the new value "Windows", this is the URL to GET: 
    139  
    140 {{{ 
    141 <yourserver/yourproject>/testpropertyupdate?realm=testcase&key={'id':'5'}&name=platform&value=Windows 
    142 }}} 
    143  
    144 == Traceability between Test Cases and Tickets == 
    145  
    146 You can open a Ticket and have a traceback to the (e.g. failed) Test Case as follows. 
    147  
    148  
    149 === Open a Ticket on a Test Case === 
    150  
    151 Whether you deploy TracTicketTemplatePlugin or not, you can get the following URL, where testCaseNumber is the Test Case complete path, planid is the Test Plan ID and planName is its name: 
    152  
    153 {{{ 
    154 <yourserver/yourproject>/newticket?testCaseNumber=TC_TT0_TC0&planId=1&planName=Test%20Plan%20for%2020100818&description=Test%20Case:%20[wiki:TC_TT0_TC0],%20Test%20Plan:%20Test%20Plan%20for%2020100818%20(1) 
    155 }}} 
    156  
    157 this will redirect to a Ticket edit page, with the Test Case in Test Plan hyperlink in the description (as Wiki page references). You can simply post the form to create the Ticket. 
    158  
    159 [[BR]] 
    160 [[BR]] 
    161 = The Python API = 
    162  
    163 TODO: To be described. 
    164  
    165 == Getting all the Tickets related to a Test Case == 
    166  
    167 '''Since: 1.4.1''' 
    168  
    169 You now have the ability to programmatically get all of the tickets that have been (explicitly) opened against a test case. 
    170  
    171 From a TestCase object, you can list the tickets opened against it in any test plan. 
    172  
    173 From a TestCaseInPlan object, you can list the tickets opened against the test case in the specific plan. 
    174  
    175 {{{ 
    176 from testmanager.model import TestCase, TestCaseInPlan 
    177  
    178 tc = TestCase(self.env, id, path) 
    179 for t in tc.get_related_tickets(): 
    180     # t is the ticket ID 
    181  
    182 tc = TestCaseInPlan(self.env, id, planid, path) 
    183 for t in tc.get_related_tickets(): 
    184     # t is the ticket ID 
    185 }}} 
    186  
    187 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. 
    188  
    189 == Registering listeners to Test objects lifecycle events == 
    190  
    191 Being based on the [wiki:TestManagerForTracPluginGenericClass Generic Persistent Class plugin], every test object supports a listener interface for components interested in test lifecycle events. 
    192  
    193 Note: The same stands for any workflow you may have attached to our test objects, by means of the [wiki:TestManagerForTracPluginWorkflow Generic Workflow Engine]. Anyway, in this case a [wiki:TestManagerForTracPluginWorkflow#IWorkflowTransitionListener specific listener interface] has been provided. 
    194  
    195 To register a listener inside the Generic Persistent Class framework, follow [wiki:TestManagerForTracPluginGenericClass#IGenericObjectChangeListener-Registeringlistenerstoobjectslifecycleevents this guide].