Selenium API Testing: Is It Possible?

Web APIs (Application Programming Interfaces) are the foundation of almost all cloud applications these days. Selenium is a very popular test automation tool for testing web and mobile applications which are powered by the cloud. So people often ask me: “Can teams use Selenium for API testing?”

This blog will explore the prospect of using Selenium for API testing in more depth.

Can You Use Selenium for API Testing?

When asked if you can do API testing using Selenium, my quick response to this question would generally be "no." While it is possible to do, API testing has got its own needs and nuances, and Selenium is not the ideal framework to address those needs.  

There are proper tools in place for API testing (such as RestAssured, JMeter, and of course BlazeMeter). The creators of these tools were very well educated about the specific requirements of API testing (and automation) when they created them. That is why specialized API testing tools should be used for testing APIs instead of Selenium WebDriver.

Fun fact, the Selenium website itself says “Selenium automates browsers.” It does not say “Selenium automates APIs.” Although the name WebDriver is slightly confusing because the web includes both APIs and frontend. It should have been Selenium UI Driver or maybe BrowserDriver instead.

We can further drill down deeper to understand the reasons for not using Selenium for API testing. I’ll start with the age-old saying:

“When you have a hammer, everything looks like a nail.”

Let me establish the correlation between the idea in question and the quote mentioned above. Selenium is often the first tool SQA professionals learn about when they are getting started with test automation. Since the only automation tool they know is Selenium, then when an API automation job comes their way, Selenium becomes an instant instinctive choice. 

That’s why I consider Selenium the proverbial “hammer” in this case and API testing projects the “nail”. A little education and training can nudge people in the right direction to save projects from unnecessary testing nightmares.

API testing tools should make it easier to call APIs and perform different assertions on them. A prime example of this phenomenon is shown in the code snippet given below, written using  RestAssured API testing library in Java.

public class RestAndTest {
   public static final String RestAssuredURL =
           "https://restful-booker.herokuapp.com/ping";
   @Test
   public void BookerPingTest()
   {
       Response response =
               RestAssured.get(
                       RestAssuredURL);
       Assertions.assertEquals(201, response.getStatusCode());
   }
}

But if you want to do the same using Selenium, you’ll need to write more code and you will have fewer options for asserting response values.

This concept can be clarified by a quick look at the example given below:

public class RestAssuredWithSelenium
{
   static WebDriver driver;
   public static final String RestAssuredURL =
           "https://restful-booker.herokuapp.com/ping";
   @BeforeAll
   public static void beforeAnything()
   {
       WebDriverManager.chromedriver().setup();
       ChromeOptions headlessOptions = new ChromeOptions();
       headlessOptions.addArguments("headless");
       driver = new ChromeDriver(headlessOptions);
   }
   @Test
   public void shouldAnswerWithTrue()
   {
       driver.get(RestAssuredURL);
   }
   @AfterAll
   public static void afterEverything()
   {
       if(driver != null)
       {
           driver.close();
       }
   }
}

The side effects of such small differences keep accumulating as project complexity grows with time.

Basically, the goals of API testing are different than the goals of Selenium-based end-to-end testing. But what are the goals of API testing anyway? 

Goals of API Automation Testing

Here are some major goals that teams can achieve with API automation testing:

1. Ensuring that various APIs of a software system are working correctly.
2. Examining the data returned by an API call. For example, the HTTP response code, and HTTP response body to verify the correctness of the API under test against a variety of inputs.
3. Modifying HTTP request headers, and parameters and asserting results.
4. Supplying valid and invalid values as parameters of post HTTP requests and validating results.
5. Calling various HTTP methods like GET/PUT/POST/DELETE on a given API URL.
6. Verifying that an API is responding correctly on edge cases.
7. Running tests often and quickly, either manually or through continuous integration triggers (CI) pipelines (Jenkins, Azure DevOps) to ensure product quality.
8. Reducing debugging effort by finding issues closer to the root cause.
9. Testing the system earlier in development, even when the UI is not available.
10. Generate API documentation automatically from API specification.

After understanding the basic goals of API testing, we are in a better position to understand why Selenium should not be used for API testing.

What Makes Selenium Unsuitable for API Testing?

Some major shortcomings of Selenium when it comes to API testing include:

1. Selenium tests are suitable for testing complete web pages, not individual APIs

Selenium is a tool for browser automation, it works on websites via browsers. It is not great at asserting if an individual API is working correctly or not. API testing tools, on the other hand, let us test individual APIs in detail.

2. Selenium doesn’t provide direct access to HTTP response codes and finer details of HTTP response

Users don’t generally look at the HTTP response codes or the body of the response in say JSON or XML format when they’re using an application through the web browser or a mobile app. That’s why Selenium does not provide direct access to these things.

API testing on the other hand often needs to examine the HTTP response in detail to assert the correctness of the application under test. The absence of these features also makes Selenium unsuitable for API testing.

Examining the HTTP response codes is very easy using API testing tools. An example of this was shown earlier in this article.

3. Inability to modify HTTP request headers and the asserting results

It is important to modify different values of the HTTP headers used by APIs under tests to ensure their stability and correctness. For example if an API expects the content type application/json but how will the API behave if we supply text/html instead. 

Selenium doesn’t allow us to set individual HTTP request headers. Proper API testing tools let us play with the HTTP headers easily and examine the results.

4. The inability to change parameters of a POST HTTP request

The HTTP POST request is used to create new records through an API. This is different from the GET request which is used to read data and we can supply request parameters through the URL.

The parameters of POST requests are not visible in the API URL. API testing often includes positive and negative scenarios where users need to supply a variety of values to the API under test for verification purposes.

5. Difficulties calling various HTTP methods like GET/PUT/POST/DELETE on a given API URL

Selenium lets us navigate to different URLs. But, it doesn’t allow us to perform different operations on them. In the case of REST APIs, accessing the same URL can have entirely different meanings based on what HTTP method (GET/PUT/POST/DELETE) is being used while making the call. Needless to say, API testing tools let us achieve this goal too. 

6. Selenium can’t be used to verify all edge-case scenarios against boundary values for API testing

Due to the reasons mentioned in the two previous points, Selenium is not suitable for verifying all API testing scenarios. We can’t change HTTP headers freely, we can’t modify HTTP request parameters freely, and we can’t examine HTTP response code as well.

7. Selenium tests are slow and resource-intensive 

The two critical components of Selenium-based end-to-end automation are a browser and the correct version of the browser driver supplied by the browser maker (Chrome Driver, Firefox Driver, Edge Driver, etc.). These two dependencies are absolutely unnecessary for API testing. Selenium tests are much slower than API tests because API tests don’t have any such dependencies.

Being heavy and sluggish means that Selenium tests are not the best choice for automated runs via CI/CD (Continuous Integration/Continuous Deployment) pipelines.

API testing tools on the other hand are comparatively lightweight and faster. They make it possible for us to perform API testing quickly with fewer resources. This helps improve product quality without being too expensive.

8 . Selenium tests don’t take us closer to the source of a defect

Selenium tests perform UI actions on a website such as

• Enter some text
• Click on some buttons 
• Retrieve values from web elements

If any of these operations fail, or an actual value does not match an expected value in an assertion, the test will fail. A developer will then need to start debugging efforts to find out the root cause of the bug from the UI. API tests take us much closer to the origin of defects as compared to Selenium tests.

9. Selenium tests are hard to scale 

If you use raw API testing tools like RestAssured, you can quickly and easily scale up your tests since the hardware requirements to run the code will be minimal. Other tools like BlazeMeter are built from the ground up to scale gracefully. Some of these tools allow us to test multiple parts of the system in parallel. We can also repurpose our API testing scripts to perform stress testing, performance testing, and load testing as well. Selenium tests are hard to scale up and you can’t repurpose them for performance/load testing scenarios.

10. Selenium tests are useless when the UI is not there

API tests can be used to verify and validate the system earlier in the development cycle. Even when there’s not a single fragment of UI in place, the API tests can still be utilized to test the APIs in detail. Selenium is a browser automation tool and it doesn’t work well when there are no “buttons to press”.

It is possible to write API tests even when the relevant API is not in place let alone the UI. We can use mocking tools such as SoapUI MockResponse to generate mock responses while a system feature is under development. 

11. Selenium can’t be used to generate API documentation

Generating API documentation from API specifications is a very useful feature that can be easily taken for granted. But, the importance of API documentation can’t be neglected. Since Selenium is not built for API test automation, it can’t generate documentation from your API’s specifications.

On the other hand, we can auto-generate documentation about how to use our APIs through tools like Postman collections. The beauty here is that these docs will also grow and evolve alongside your APIs throughout the development process.

Bottom Line

If you’ve gotten this far, you’re definitely serious about your work. Plus I’m sure you now have clarity about why you shouldn’t use Selenium for API testing and why you should use proper tools for automated API testing.

As a parting remark, I’d like to share with you a quote by a Chinese philosopher:

“Don’t use a cannon to kill a fly.”

Run your API tests with a tool built for API quality and performance. Explore how BlazeMeter can help you achieve your API testing goals today.

Start testing now