pondělí 19. prosince 2011

Functional requirements of tool for REST testing

In this blogpost, I am going to propose functional requirements of tool which should test REST constraints of some API. Do you think there are some more? Feel free to share them in comments.
  1. Inserting an API entry point
    Application will provide a form for specifying an API entry point. This form will consist of following fields:
    • text field for API's entry point URL address
    • a field for selecting an HTTP verb to use on that address
    • optional fields for specifying custom headers
    • optional field for specifying request body
    After the form is filled, the user can execute runtime testing by clicking the send button.
  2. Runtime asking
    During runtime testing, the application traversing through API from specified entry point using Uniform Interface. However it might be required to modify some of automatically generated requests. For that purpose there is runtime asking form which includes following fields:
    • exclusion button for exclusion this request from runtime testing
    • optional fields for specifying custom headers
    • optional field for specifying request body
    After the desired inputs are filled, the user can save the modified request by save button.
  3. Displaying of runtime testing results
    The application is displaying discovered resources in tree structure with informations about REST constraints fulfillment such as cacheability and auto discovery capabilities. The tree displaying should be optimized for viewing at mobile devices as well as on computer screens.
    Every resource in tree should allow editing of its request details by Runtime asking form and should be re-runnable manually.
  4. Saving state and result of runtime testing
    The application can save and export current state of runtime testing and currently obtained results.
  5. Restoring state and result of runtime testing
    The application can restore or import state of runtime testing and obtained results and allow its continuing.
  6. Response correctness checking inputing
    The application allows user to manually enter expected response of particular request. The user do this by filling a form which contains:
    • text field for resource's URL address
    • a field for selecting an HTTP verb to use on that address
    • optional fields for specifying custom headers
    • optional field for specifying request body
    • area for specifying expected response code, headers, body
    After the form is filled, the user can save that expected response by save button.
  7. Response correctness checking generating
    The application allows user to generate a set of expected responses to requests from API documentation. The user do this by specifying API's documentation path.
  8. Response correctness checking evaluating
    The user can run and review previously inputed (generated) response correctness in table form. Each row for one request/response test with information about if passed or not passed.
This above would be my wish-list about functional requirements for REST API testing application. There is much likely more what should it do, for example I omitted stress testing in this stage of development. If you have any comments, suggestions just let me know.