In my current testing project one part of testing strategy is to test REST api endpoints of web application independently for user interface. Application is in early stage and documentation is in great volatile state. There is testing environment dedicated to testers and there is new release deployed on it almost every second day. I choose curl and Ruby httpclient gem as testing tools and assistance in this task. In this post I will explain usage context for each tool.
As documentation for api endpoints is still very volatile, I need a way to explore each of api endpoints. REST API endpoints are explored using following inputs:
- method type: HEAD, GET, POST, PUT, DELETE
- headers: set restricted to headers sent by latest Chrome version
- parameters: query for GET and parameters for POST, PUT and DELETE
When I stop testing api endpoint using curl (using for my stop testing criteria api endpoint feature coverage using endpoint inputs), then I code in Ruby application automation testing framework using httpclient, json_spec (api endpoints input and output are in json format) and rspec as testing framework. In order to achieve flexibility as in curl, I had to investigate httpclient gem documentation and had to test developed application automation testing framework output by directing traffic through ZAP proxy. Using proxy I discovered that httplib gem is smart enough to automatically populate Cookie header, based on previously received Set-Cookie headers (there where duplicate Cookie headers, one set by automation framework and one set by httpclient). This is super functionality if you are developer of HTTP client, but for tester this reduces their flexibility to trigger errors. For example, I created a test case where I would like to know information does application properly handles http sessions stored in cookie header. Fortunately, there is property that turns off automatic cookie population.
Another example was that I was not able to send duplicate parameters (with same name) as POST parameters.
As in real life, every tool has its usage context, so testers should wisely choose which tool to use in which context in their testing job.
