Changes between Version 15 and Version 16 of TestManagerForTracPluginApi


Ignore:
Timestamp:
Jan 20, 2011, 4:52:56 PM (13 years ago)
Author:
Roberto Longobardi
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].