My Universal, High-Efficient and Free Approach to API Testing

Ruby Scripting with Templates and Executing in a BuildWise CT server frequently

Long-time readers know I usually write about Web Test Automation and Continuous Testing, touch API Testing very little. The reason: I think API testing is really simple, at least with my highly efficient and universal (proven with 20+ years) approach. This article shares my approach.

Some readers may wonder after seeing the title, “Putting ‘Universal’ & ‘Free’ aside, High-Effcient? Proof?”. Check out my article, A Story of 100X API Testing I Implemented in a Matter of Days. Yes, I have been archiving typically 10X to 100X productivity (compared to others) over the past 20 years with this approach.

My daughter and I have written a few case studies for the most common form of API testing:

• SOAP Web Services

• RESTful Services

• GraphQL

Astute readers would figure out I used the same approach: Ruby Scripting with Templates and Executing in a BuildWise CT server frequently.

API Testing is simple, essentially, a computer program exchanges data with another based on an agreed protocol. Most API Testin is based on HTTP protocol, sending data (typically in the form of XML or JSON) over HTTP requests (e.g. GET, POST, PUT, DELETE). However, over 15+ years of test automation consulting, I found most API Test Automation failures due to making it complex, typically got mixed by some commercial API Testing tools, such as SoapUI Pro/ReadyAPI and Postman.

Table of Contents
∘ My Universal API Testing Approach
∘ How did I come up with this approach?
∘ Only use GUI Tool as a helper utility
∘ Run your whole API test suite often in a Continuous Testing Server
∘ FAQ

My Universal API Testing Approach

I will illustrate my approach with SOAP services testing.

Java/C# programmers often use generated Stub (based WSDL) to invoke APIs, and some apply the same way to API Testing. It can work, but is too complex.

Invoke SOAP web service is simply sending (HTTP POST) a defined XML to a service endpoint (URL), in other words, a form of XML over HTTP.

1. Find out the service end-point.
   This is either provided or can be easily get.

2. Get the skeleton (or template) of the request XML.
   Use SoapUI (free edition) or other tools to generate a sample from WSDL.

3. Construct the request XML message
   Adding dynamic to the request XML template.

4. Send the message to the endpoint via HTTP POST
   using an HTTPClient library.

5. Parse the response message.

I have been testing SOAP services this way for numerous projects since 2003, accomplishing the key scenario testing, usually under an hour.

For more on this approach, check out my book, API Testing Recipes in Ruby.

This approach can be used in code too, e.g. invoke SOAP services directly.

I recall the time when I successfully integrated with the government payment service, and it only took a few hours. The support engineer was pleasantly surprised. He asked, “How did you integrate so quickly? Because other government departments usually took weeks or months.”

I answered, “I didn’t invoke your SOAP services via Stub, as in your documentation. I just invoked the service by sending the XML over HTTP POST”.

The support engineer, paused a few seconds, “Fine, as long as it works.”

How did I come up with this approach?

I worked three years at a research centre, and my unit has another title, “W3C Australian Office”. Therefore, I am quite familiar with HTTP protocols. Also, I implemented a simple metadata search engine in Perl (initially) and Java, those experiences helped me to be comfortable with text manipulation, especially using a scripting language.

Later, following the advice of the classic “The Pragmatic Programmer”, I self-learned Ruby. Wow! What a wonderful language!