{"id":6804,"date":"2017-12-08T08:53:10","date_gmt":"2017-12-08T13:53:10","guid":{"rendered":"https:\/\/qxf2.com\/blog\/?p=6804"},"modified":"2024-10-16T16:04:41","modified_gmt":"2024-10-16T20:04:41","slug":"easily-maintainable-api-test-automation-framework","status":"publish","type":"post","link":"https:\/\/qxf2.com\/blog\/easily-maintainable-api-test-automation-framework\/","title":{"rendered":"Easily Maintainable API Test Automation Framework"},"content":{"rendered":"

For a long time, Qxf2’s API tests were not really object-oriented. We were relying on (at best) a facade pattern or (at worst) the God class anti-pattern. Our colleague, David Schwartz of Secure Code Warrior, helped us make our API automation framework more object-oriented and easier to maintain. Thanks, Dex, for all the guidance, examples, code, code reviews and for helping us improve our API tests!<\/p>\n

We have not yet managed to implement everything we learned from Dex. By no means we are claiming this is a good, ‘final version’! But we felt our API automation framework had improved enough to share at least a skeleton. We genuinely feel that you could benefit from seeing the code at this stage and then improve from here.<\/p>\n

\n

For this example of Player-Interface layer based API Automation Framework, we have written a sample API application called cars_app.py<\/strong> using Python Flask and created Python based automation tests. That way, you can follow along easily.<\/p>\n

 <\/p>\n

Following image represents workflow of the framework, click on it to enlarge<\/h5>\n

\"\"<\/a><\/p>\n

We’ll spend the next few sections looking at each block along with a useful code snippet.<\/p>\n

 <\/p>\n

Base Mechanize Module<\/h5>\n

We use a Python module called Mechanize to make our REST calls. The Base Mechanize module includes wrappers for the Mechanize API calls like GET, POST, DELETE, PUT. These methods return JSON response with status code\u00a0 or\u00a0 error details with status code for further debugging. Requests is another popular Python library that many people prefer. You can easily substitute Mechanize wrappers for Request wrappers.<\/p>\n

code snippet for example:<\/p>\n

    def get(self,url,headers={}):\r\n        \"Mechanize Get request\"\r\n        browser = self.get_browser()\r\n        request_headers = []\r\n        response = {}\r\n        error = {}\r\n        for key, value in headers.iteritems():\r\n            request_headers.append((key, value))\r\n            browser.addheaders = request_headers\r\n        try:\r\n            response = browser.open(mechanize.Request(url))\r\n            response = json.loads(response.read())\r\n        except (mechanize.HTTPError, mechanize.URLError) as e:\r\n            error = e\r\n            if isinstance(e, mechanize.HTTPError):\r\n                error_message = e.read()\r\n                print(\"\\n******\\GET Error: %s %s\" %\r\n                (url, error_message))\r\n            else:\r\n                print(e.reason.args)\r\n            # bubble error back up after printing relevant details\r\n                raise e\r\n\r\n        return {'response':response,'error':error}\r\n\r\n<\/pre>\n
ENDPOINTS LAYER<\/a><\/h5>\n
The endpoints layer abstracts the endpoints of the application under test. We create one endpoints\/[$feature]_endpoint.py<\/u> file. Each [$feature]_endpoint.py<\/u> file contains a class that has methods related to all the endpoints for that features. For example, our cars_app.py application has an endpoint (\/register) related to registration. The [$feature]_endpoint.py<\/u> should not contain any business logic or test logic. It should simply be making REST calls to specific endpoints and returning the data it sees. You could choose to return everything that the REST call has in its response or reorder the response with just the bits you want.<\/p>\n
code snippet for example<\/p>\n
\"\"\"\r\nAPI endpoints for Registration \r\n\"\"\"\r\nfrom Base_Mechanize import Base_Mechanize\r\nclass Registration_API_Endpoints(Base_Mechanize):\r\n\t\"Class for registration endpoints\"\r\n\r\n\tdef registration_url(self,suffix=''):\r\n\t\t\"\"\"Append API end point to base URL\"\"\"\r\n\t\treturn self.base_url+'\/register\/'+suffix\r\n\r\n\r\n\tdef register_car(self,url_params,data,headers):\r\n\t\t\"register car \"\r\n\t\turl = self.registration_url('car?')+url_params\r\n\t\tjson_response = self.post(url,data=data,headers=headers)\r\n\t\treturn {\r\n\t\t\t'url':url,\r\n\t\t\t'response':json_response['response'].read()\r\n\t\t}\r\n<\/pre>\n
<\/h5>\n
INTERFACE LAYER<\/h5>\n
This layer is a composed interface of all the API endpoint classes. In our cars_app.py application we have features related to car details, registration and users.<\/p>\n
code snippet for example :<\/p>\n
\"\"\"\r\nA composed interface for all the API objects\r\nUse the API_Player to talk to this class\r\n\"\"\"\r\nfrom Cars_API_Endpoints import Cars_API_Endpoints\r\nfrom Registration_API_Endpoints import Registration_API_Endpoints\r\nfrom User_API_Endpoints import User_API_Endpoints\r\n\r\nclass API_Interface(Cars_API_Endpoints,Registration_API_Endpoints,User_API_Endpoints):\r\n\t\"A composed interface for the API objects\"\r\n\r\n\tdef __init__(self, url):\r\n\t\t\"Constructor\"\r\n\t\t# make base_url available to all API endpoints\r\n\t\tself.base_url = url\r\n<\/pre>\n
<\/h5>\n
PLAYER LAYER<\/h5>\n
This is the layer where business logic and test context is maintained. The player layer does the following:<\/p>\n