TestArchitect Corner: Codeless API Testing

API testing has long been misunderstood as well-confined in the territory of developers. It’s natural to think that we must write code to test our code. However, it doesn’t have to be that way anymore. Business testers who have deep domain knowledge are now able to take on the challenges of API testing without coding. That approach is called “Codeless API Testing”. In this article, we’ll examine how business testers perform codeless API testing using TestArchitect.

What is web service testing?

As we all know, web services are applications that can be published and called over the Internet by client applications. Think of a web service as the communication medium, through which two applications exchange data regardless of their underline architecture and technology.

Most of today’s client applications crucially depend on complex web services. Thus, ensuring the robustness of those web services from both functional and non-functional aspects is almost always obligatory, much like a social contract.

It is unarguably vital to execute functional and integration testing on your web service during pre-deployment stage to identify and resolve defects as early as possible, and performance/stress testing during post-deployment stage to assure service responsiveness and availability.

Planning a web service functional test

Before creating any test procedure, plan your web service testing as follows:

  • Define which service functionality should be tested.
  • Determine which APIs of the service with specific versions are to be verified. It’s preferable to take advantage of machine-readable service description languages such as WADL and WSDL.
  • Specify which APIs to be called, the call order and how you verify the returned HTTP results (usually either in JSON or XML format).

After planning your test, we can now start creating our test suite.

A basic web service test

Almost all of web services these days fall under either SOAP or REST. Anyhow, a web service test typically consists of the following steps:

  1. Authenticate.
  2. Construct the http request.
  3. Send the http request & get the response.
  4. Parse & check the http response.

Below is an example test scenario written in Action-Based Testing Language (ABTL). Note that our web service under test is JIRA’s REST API. In this test scenario, we’ll create a bug on JIRA and check whether it is created successfully and its ID follows the correct format.

As you might notice, the above test scenario consists of several actions instructing how TestArchitect interacts with the web service.

The first step is authentication. TestArchitect supports two main methods:

  1. Basic HTTP authentication
  2. OAuth 2.0

In this example, we use Basic mode by encoding username:password in Base64 format.

An online Base64 encoding tool for your convenience is here. For more information about specifying credentials, check out this article. JIRA’s Basic authentication mode is described here.

Next, we prepare the data for the JIRA issue to be created. It’ll be a bug belonging to a fictional project.

“POST issue” is a high-level action which, creatively enough, sends an http POST request to the respective API. The detailed content of “POST issue” action is below.The above JSON string describes the specifics of the bug we’re posting. This bug belongs to the project whose keyword is “FOR”. Its summary says “Something’s wrong”. IssueType with ID=1 is a bug. The rest of the string specifies the Assignee and Reporter fields respectively.

This “POST issue” action takes in “issue” argument and returns the http response as “variable” argument.

create http request instantiates a new http request object which the ensuing test lines define. add http header states that the request’s content type is JSON. Note: if you’re sending a GET HTTP request, you can add parameters using add http parameter.

add http body encloses the issue’s information we prepared above. Finally, TestArchitect sends the pre-defined http request to the corresponding URL as a POST message. It expects the return status to be 201 (success) and the rest of the response will be stored in “variable”.

Let’s get back to the test module. After posting the issue, we need to parse http response and store the body in the “json” variable.

The last step is to verify the key of the newly created issue follows the correct format (“FOR-XXX”) using a regular expression (.*). When the test passes, you’ll observe a similar result as below.Any JSON strings can be parsed using get json query result in TestArchitect. Note that you have to provide a JsonPath (see the bubble on the next page) to tell TestArchitect what piece of data to retrieve. In this specific example, we want the “key” field stored in the “key” variable.

What is JsonPath?   Much similar to the use of XPath in XML documents, JsonPath is the querying language that helps you retrieve certain chunks of a JSON tree structure without parsing the string on your own. The dollar sign ($) represents the root node in the JSON tree structure. With TestArchitect, you can simply omit that dollar sign for better readability. Use dots (“.”) to denote parent-child relationship among node names. For instance, this path $.phoneNumbers[2].number gives you the 3rd phone number (indexes start at 0) in the list named “phoneNumbers”.The bracket-notation is not supported. For more information, refer to this article.

More comprehensive test scenarios

TestArchitect empowers you to do much more than the above basic test scenario:

  • Your test scenarios don’t have to stop at testing only one API. With the above package of built-in actions, you can create service integration tests jumping from one API to the next.
  • Better yet, you can create end-to-end service tests by reusing user-defined actions, such as insert product or delete product. Doing this will elevate the abstraction of your tests from low-level HTTP interactions to high-level business logic actions, which are obviously much more meaningful to Business Testers.
  • Check points aren’t only confined to JSON but also XML and database actions such as check xml query result or execute sql. For instance, you can compare the HTTP response in JSON format from a web service to a data record retrieved from a database.
  • You can create one set of tests that can be executed at UI-level and service-level using TestArchitect’s Multivariate feature.
  • You can mix UI and service operations in user-defined actions when necessary.
  • You can manage your test data within TestArchitect.
  • You can perform Service Virtualization with TestArchitect as shown below.

Auto-generating Codeless Tests for API

TestArchitect also supports you to auto-generate codeless tests for API using webservice description files, e.g. WSDL files and WADL files. You can simply specify the WSDL or WADL file and TestArchitect will automatically detect the possible codeless actions that you can generate. See the picture below.

To obtain this version of TestArchitect, please contact our team at sales@logigear.com.

Important Note Codeless-ness is by no means a golden handcuff. If you prefer coding, you can still create user-scripted actions in the TestArchitect harness (available in C#, Java and Python) to programmatically perform any tasks such as retrieving test data from another web service or database. Harnesses allow developers and QA to work hand in hand to foster “Integrated Integration Testing”. Exclusive: In this article, Jake Wallingford tells the story of how his team facilitated tight collaboration between developers and QA to create better integration tests by utilizing TestArchitect.


With all these capabilities at your fingertips, you and the rest of the Business Testers can now start being productive right away with minimal coding needed.

Stay tuned for the upcoming article discussing how you can Dockerize TestArchitect components to test your web service hosted in a Docker container as easily as flipping a switch.

To learn more about TestArchitect features and supported platforms, read on here.

Happy testing!

If you don’t have TestArchitect to try the above instruction, you can see TestArchitect in action in the below video.

Get TestArchitect Team Free

Thuc Nguyen
Thuc Nguyen has been leading the product teams at LogiGear in delivering quality Test Automation solutions to LogiGear’s customers and services clients. Thuc has a great passion for helping organizations transform their Test Automation, Continuous Delivery and DevOps practices, as well as empowering testers of all technical levels to thrive in complex enterprise environments.
Thuc Nguyen on Linkedin

The Related Post

APIs are subtly altering our expectations that there should be an app for everything. The concept of disruption has been given regal status across businesses, startups, and tech circles in recent years. With such great emphasis placed on change, user experiences are inevitably facing evolution as well. Application programming interfaces or APIs have great transformative powers to disrupt business, but are ...
APIs are the unsung hero of our connected world We live in an exciting age of intelligence, where progress moves at the speed of imagination. We are connected to the world and one another like never before. API (Application Programming Interface) is the unsung hero of our connected world. Here’s everything you need to know ...
An approach to secure maintainability and scalability for API testing projects One of the most important tasks in API testing is designing the input data whose quantum could explode due to the combination of a vast number of arguments. An experienced tester will inevitably figure out the advantages of the pairwise method in efficiently picking ...
Social APIs are omnipresent and create special cases for testing. If you understand API testing, especially web service type APIs, testing social APIs is easy to grasp. The use of social APIs makes them a special case. They are omnipresent and very well understood. What this means is you need to have a good understanding ...
A case-study using: Java, REST Assured, Postman, Tracks, Curl and HTTP Proxies This is the first book review I have written on my site. So of course I had to choose a great book that was relevant to my niche. Alan Richardson’s book on Automating & Testing a REST API fits the bill perfectly. I am a big ...
An API provides much of the functional capabilities in complex software systems. Most customers are accustomed to interacting with a graphical user interface on the computer. But, many do not realize that much of the functionality of a program comes from APIs in the operating system or the program’s dynamic-link libraries (DLL).
Here are some books you might find useful when developing your web services API testing strategy. The Art of Application Performance Testing by Ian Molyneaux — This book was just released and I found it an outstanding conceptual overview of performance testing a web based application. The book does a great job of reviewing the ...
An overview of web service testing solutions for traditional or non-technical testers. Much has been written on the technical execution of API tests, yet there are gaps in the details of what tests to design and how to design them. The articles tend to either get too technical too fast, or are too vague and ...
 Understanding the pieces of the web service testing puzzle can make testing easier For people wanting a broader understanding of more pieces in the web service testing puzzle, here is a breakdown of the various possible components of an API.
Summary Remember that Agile is not an SDLC. Neither are Scrum and XP for that matter. Instead, these are frameworks for projects; they are built from practices (for example, XP has 12 core practices). Scrum and XP advocates will freely recommend that you pick a few practices to implement, then keep what works and discard ...
API testing is different from GUI testing, but it doesn’t take long to master. What is an API? API is an acronym for Application Programming Interface. It enables communication and data exchange between two separate software systems. A software system implementing an API contains functions/subroutines which can be executed by another software system.

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news