Changes between Initial Version and Version 1 of TestManagerForTracPluginRestfulApi


Ignore:
Timestamp:
Jan 20, 2011, 5:40:55 PM (4 years ago)
Author:
seccanj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TestManagerForTracPluginRestfulApi

    v1 v1  
     1= Test Manager for Trac Plugin - The HTTP RESTful API =
     2
     3[[BR]]
     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 verdicts of Test Cases in a plan.
     5
     6This page describes the '''HTTP RESTful API''', but there are alternatives:
     7
     8 * An '''XML-RPC''' API, allowing you to remotely control your test artifacts using a standard protocol, 
     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.
     10 
     11[[BR]]
     12In the following, because of the spam filter not allowing more than a few URLs in a page, I have replaced:
     13
     14{{{
     15http://yourserver/yourproject
     16}}}
     17
     18with:
     19
     20{{{
     21<yourserver/yourproject>
     22}}}
     23
     24== Working with Test Catalogs and Test Cases ==
     25
     26You can create test catalogs and cases programmatically by means of the following http requests.
     27
     28
     29=== Create a root test catalog ===
     30
     31Get the following URL:
     32{{{
     33<yourserver/yourproject>/testcreate?type=catalog&path=TC&title=My%20new%20catalog
     34}}}
     35this 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):
     36
     37{{{
     38<yourserver/yourproject>/wiki/TC_TT0
     39}}}
     40
     41=== Create a sub-catalog ===
     42
     43Get the wollowing URL, where "path" is the name of the parent catalog.
     44
     45<yourserver/yourproject>/testcreate?type=catalog&path=TC_TT0&title=My%20sub%20catalog
     46this 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):
     47
     48{{{
     49<yourserver/yourproject>/wiki/TC_TT0_TT1
     50}}}
     51
     52=== Create a Test Case ===
     53
     54Get the following URL, where "path" is the name of the parent (sub-)catalog.
     55
     56{{{
     57<yourserver/yourproject>/testcreate?type=testcase&path=TC_TT0_TT1&title=My%20new%20Test%20Case
     58}}}
     59
     60this 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):
     61
     62{{{
     63<yourserver/yourproject>/wiki/TC_TT0_TT1_TC0
     64}}}
     65
     66
     67== Working with Test Plans and setting the status of a Test Case ==
     68
     69You can also create a new Test Plan (e.g. for each nightly build) programmatically as follows.
     70
     71
     72=== Create a Test Plan from a specific catalog ===
     73
     74Get the following URL, where "path" is the name of the (sub-)catalog to create the test plan against.
     75
     76{{{
     77<yourserver/yourproject>/testcreate?type=testplan&path=TC_TT0&title=Test%20Plan%20for%2020100818
     78}}}
     79
     80this 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):
     81
     82{{{
     83<yourserver/yourproject>/wiki/TC_TT0?planid=1
     84}}}
     85
     86The Test Plan will contain all of the test cases in the specified catalog, with a status of "Untested".
     87
     88Note: 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.
     89
     90
     91
     92=== Set a Test Case execution verdict, in the context of a Test Plan ===
     93
     94Then, you can set the verdict for any test case in the plan, by means of the following.
     95
     96Get the following URL, where "id" is the Test Case ID and planid is the Test Plan ID:
     97
     98{{{
     99<yourserver/yourproject>/teststatusupdate?id=5&planid=1&status=SUCCESSFUL
     100}}}
     101
     102The supported statuses are currently:
     103
     104 * TO_BE_TESTED
     105 * SUCCESSFUL
     106 * FAILED
     107
     108
     109== Change a [custom] property of any test object ==
     110
     111Any property, either standard or custom, of any test object can be set programmatically through the RESTful API.
     112
     113A 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).
     114
     115The realms that identify the test objects are the following:
     116
     117 * Test Catalog: testcatalog
     118 * Test Case: testcase
     119 * Test Case in the context of a plan (i.e. with a status): testcaseinplan
     120 * Test Plan: testplan
     121
     122The realm must be provided to the property update service through the "realm" parameter.
     123
     124The corresponding key properties, needed to identify any particular object, are:
     125
     126 * Test Catalog: id
     127 * Test Case: id
     128 * Test Case in the context of a plan (i.e. with a status): id, planid
     129 * Test Plan: id
     130
     131The key properties are provided to the property update service through the "key" parameter, in the form of a dictionary.
     132
     133The 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.
     134
     135For 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:
     136
     137{{{
     138<yourserver/yourproject>/testpropertyupdate?realm=testcase&key={'id':'5'}&name=platform&value=Windows
     139}}}
     140
     141== Traceability between Test Cases and Tickets ==
     142
     143You can open a Ticket and have a traceback to the (e.g. failed) Test Case as follows.
     144
     145
     146=== Open a Ticket on a Test Case ===
     147
     148Whether 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:
     149
     150{{{
     151<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)
     152}}}
     153
     154this 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.
     155