How to use API Tester - manuskc/API_Tester GitHub Wiki

This is a testing utility to test any REST based api or basically any web end point.

• To add a test case, create a file with '.test' extension.

• Every file can contain as many number of test cases as you want.

• The format of the file is an array of JSON object.

• The first object of the array is reserved for config ( wow! config and simplicity does not sound good together - just to make things simple for now, you can just leave it empty. Later you will see this object makes things more simple)

• All other objects in the array represents a test case and they are executed sequentially.

• An object must contain two parameter 'request-url' and 'response' where the 'request-url' represents the end point to be tested. And 'response' represents the expected response.

• To run the test cases execute tester.py :
  Note:

  • if no parameters are passed to tester.py it tries to execute all .test files (in order of their names) in the current directory
  • if a directory path is given as a parameter, all the test files in the directory are executed in the order of their names
  • if a path to test file is given as a parameter the test cases in that file are executed it ignore any extra parameters passed!

Cool, You do not have to write a complex regular expression to match your response just use a 'message-filler' in the parts of response that you do not know what the exact value will be.

Example: If the response is (say app-id in the following response is generated randomly):

      <status>APP CREATED</success>
      <app-id>101</app-id>

Then your test case object as follows:

     {
       'request-url': 'http://myapi.com/endpoint',
       'request-data': { 'param1':'value 1','param2':'value 2'},
       'response':'<status>APP CREATED</status>\n<app-id>####</app-id>',
     }

'####' is the default 'message-filler', you can define your own 'message-filler' text pattern by defining that parameter in the test case object.

Since the .test file has to be a valid JSON file it has to be in one line, you need to replace line breaks with '\n' and define your response. But wait, if you are really not bothered about white spaces like new line, tabs, spaces etc you need not have to escape line breaks or type in exact number of spaces and tabs you just need to 'ignore-whitespaces'. Yes, just add a parameter 'ignore-whitespace' and set its value to 'true' in the particular test case and All the white spaces, line breaks will be ignored while comparing the result. By default this parameter value is 'false'

By default it is a GET call, but if you want to change it you can set 'request-method' parameter of the particular test case to 'get' or 'post' as needed.

No need to, that is why we have our first object in the test case! Treat this object as global space which is shared by all test cases. Any parameter you define is default for all the test cases unless you override by defining it in the test case again. Any parameter defined with in a test case object has its effect only within the test case.

Note: This object is used for other purposes internally, so better not define your own parameters unless you go through the source and make sure that will not conflict any where. (yup, just grep for the parameter name, if you dont find it you are good to add the parameter)

Didn't i say this object will make things more simple?

Of course you can! Since you provide the expected response you will know the data in response, except the part matched by 'message-filler'

You can access the value stored in a message filler by {$n} format. where n is any number and it represent's the string matched by n'th occurence of 'message-filler'

You can define 'name' for each test case so that it is easy to read test results! Also since you can define any parameters - you can document it well with 'comments'

I am planning to add a web ui with add and run test cases, set up jobs to execute tests and even before that add more feature to the utility, one on top of my mind right now is to add a feature to actually subject the strings matched by 'message-filler' to a regex pattern if required ( Did i say regex is complex, its powerful and i love it!) and also allow multiline response strings.