DEV Community: Manuel Mariñez

API testing tools: An Example Based Guide

Manuel Mariñez — Sun, 02 Aug 2020 03:55:00 +0000

For API testing there are a lot of tools out there that let you perform the test and collect the results. In this article, I’ll be focusing on three tools by straight-up showing how to do a request using the Trello API.

But before we start, since we are going to use the Trello API we will need an account, an authorization key, and token. For API testing and development, this is a pretty common step that is used for security measures since through APIs we can have access to databases and internal functionalities of the code that could be exploited by malicious users. For that, I’ll leave this link with all the steps you need to get started, you can find these steps in the API introduction right below the “Authorization and authentication” section (you will see this as soon as you click on the link).

Once you are all set, let’s get started with the API testing tools.

OS Terminal

For the example, to get a response from our API using the terminal we will need the command line called “curl” which is commonly used in a lot of softwares to, you guessed it, transfer data from one another

We are going to add the following command in the OS terminal:

curl --location --request GET 'https://api.trello.com/1/members/me/boards?key={your-key}&token={your-token} -I'

From here we get all headers

And at the top is the status code for our response.

A cool feature is that we can save the response in a file in case we need it later on for a scan or to validate some of its fields. This can be done typing the command once again with a simple flag “-o [name of the file]”. For example “-o test_response.txt”

Once you do that you should see in your terminal a meter indicating the download progress

If you prefer not to add a name to the file just add the flag “-O” to save the file with the URL as the file name.

And finally for when we need to create, update or delete from the cURL we add the following commands according to what we need “-X POST” “-X PUT” “-X DELETE” alongside the “ --data-raw ‘{“param”:”value”}’ ”

Now let’s see how the next tool can handle these same scenarios and what features does it bring to the table:

POSTMAN

With postman, we get all the information we need with just one click. Let see the examples below:

As soon as we send our request we get more information than we can ask for. For starters we get the full response with a pretty format so is a lot more readable and we don’t have to format it on our own, then we have the status code so we know if the request was successful or not, in this case, all went as expected and we got a 200 status code and also a dedicated tab to add params and its values which are directly added to our request URL.

We get all the information we got from the OS terminal in just one click, which saves us time and effort in order to be more efficient at testing our API.

With that example, there are other key features that postman gets to our disposal like saving our request into a collection (Set of request URLs saved into a folder) in which we retrieve the URL at any moment without typing it into the input all over again.

We can also export the request for further use into a test report or run it into a CI tool like circleCI or Jenkins.

Postman gives us the chance to work with multiple requests in different tabs.

In case we need to get the request in a particular language it gives us the code snippet to do so by clicking code in the params type.

We can manage different environments in which we can store different variables, the variables can be named however the user wants and assign the values, like the common parts of the request URL so the user just has to handle the request

A history of all the requests we have done recently so the user can go back and do the same request with specific params or just execute it once more.

Postman has a dedicated section to add scripted tests in Javascript.

It includes predefined code snippets we can use.

A console where we can see our response HTTP and print messages.

These are what I consider the key features that postman let us work with to have a smoother experience while testing with API in general.

SoapUI

Let’s keep going with the same example

Our first impression of SoapUI as soon as we enter is that it will prompt us with the endpoint explorer which lets us make the request to our Trello API like previous tools but in this case like the terminal, we get a raw text response.

Also, it can be noticed that we can add headers to our request in case we need authorization for example, and that at the top of our raw text we have the response status.

At the bottom, we can see the unformatted JSON with the data that we need. Unfortunately from the Endpoint prompt, we can’t make it look pretty so what we need to do is inside a project. The first step to do so is to click on the save request (blue) button right next to the send (green) button.

Set Up a name for your request to save it and click the OK button, this action will create the project that will be displayed to the left side of the program.

Double click on “Project 1” (you can right-click on it if you want to change its name) and you will have an overview of all the components of your project, but for now, I’ll focus on the request. Expand the project folder until you request the request which is in the last layer and click “TrelloAPI”.

As soon as you click on the send request button you will notice a message that says “The content you are trying to view cannot be viewed as XML” that is because is the default of multiple views we have for our response, to the left side you will notice four tabs XML, JSON, HTML and Raw.

Click on JSON and we will get the pretty formatted response.

You can check the other tabs whenever applicable.

SoapUI gives us a big variety of features to let us apply API testing more efficiently. The first one I would like to highlight is setting our tests into test suites each one with their test cases and test steps making it easy for the tester to group the tests in logical units.

Support for WSDL and SOAP services

Load and security testing dedicated inputs for testing

Disadvantages

For this section, I’ll be adding things to consider for each of the tools so you can choose depending on your work environment and necessities.

OS Terminal

Lack of user interface and hand-holding. This is the most obvious since the user would need previous knowledge of the commands that are needed to send the requests and get the response in a readable format. The terminal can be customized to ease this problem but it would be an extra layer of configuration outside the main purpose of testing.

Postman

Missing test monitoring. This missing functionality can be a let down to many developers or testers in case they wanted to rely on a single tool to work on all testing suites.

SoapUI

Learning curve. SoapUI is a powerful tool but it comes with some challenges and a not so user-friendly interface. It will take some time for the user to understand the project structure based on the different components like test suites, test cases, assertions, and load tests to get full advantage of the tool.

For Postman and SoapUI, there are some features that are behind a paywall but I don’t consider that it is necessarily a disadvantage since those features are mostly to work with a team of 5 or more people requiring to share a project. But for an individual user, the features available for free are more than enough to get the job done.

Final Thoughts

Up until this point we have seen some of the features on each tool following one scenario, in this article I’ve talked about features that are not related to the automated testing since I think that should be a topic of its own. Each tool has pros and cons comparing them to each other, but all of them can help the tester depending on the requirements of the test assigned, it would be up to the tester to decide what strategy to follow with one of these tools.

What are APIs? and How can they enhance your testing?

Manuel Mariñez — Wed, 24 Jun 2020 04:28:01 +0000

An API (Application programming interface) is a set of tools that are used to build software and also make them communicate with each other. The way this is done is by using REST for formatting the information payload requested by the client with a standard text format like JSON, XML or raw text, then the data is sent to the server with HTTP methods like GET, POST, PUT and DELETE to name a few, the server then interprets the data, performs the action requested and sends the data back to the client.

As technical as that definition can be it took me some time to get it all together, there are way too many good and extended definitions of what an API is, but it all can be summed up to an analogy that you have probably seen in a youtube video or another blog.

“You (the client) are in a restaurant and you wish to order food to the kitchen(the system) here is when the waiter(API) comes in to take and deliver your order to the kitchen, then the kitchen prepares your order and the waiter comes back with the food order requested.”

A real-world example of this is whenever we want to sign in to a web application like Gmail.

We fill the required fields like email address and password, then the API takes that information to the system, then the system validates if the email and password are stored in the database and depending on the outcome of the validation the API returns with the webpage bypass access to the user, a message saying that the action could not be completed because the user is not registered, the username is not valid or that the password is incorrect. APIs are under the hood operations that are not visible to the user while it is in the GUI (Graphical User Interface).

Getting familiar with APIs and how they work gives a wide number of advantages from building and optimizing your software to knowing how to test key features that are the main interest of the business. This part is important because APIs are seen as part of the business layer of the software architecture.

As software testers, we can expand our test scope in a significantly more efficient way since there is no GUI interaction, the test scenarios can be executed and the results can be collected a lot faster. For example.

Test Scenario: Validate input search

Test Cases:

Check the input search with an empty field.
Check the input search with special characters.
Check the character limit in the input search.
Check the input search with SQL expression.
Check the input search with HTML tags.

As you can see this scenario is not different from what we could do in a GUI but with the twist that we don’t have to open a web browser to access the URL, look for the specific input search that needs to be tested and then applying the test cases. All this can be done by simply sending a GET request with the correct URL and the desired parameters or variables.

To perform the tests there are several tools that can be used from an OS terminal to dedicated software like Postman or SoapUI. I’ll cover these tools in part 2 where I’ll go through its features, advantages, and disadvantages.

Console Messages in Test Automation Reports: Implementation and Advantages

Manuel Mariñez — Sun, 26 Apr 2020 14:55:50 +0000

The web console, also known as f12, hacking screen and many other names that made you believe that you were a web developer by changing HTML tags to place your name in a big bold title.

With that said, for this tutorial I want to highlight the selenium feature to capture those web console messages that can get us a good idea of what could be causing an error in our AUT(Application Under Test), in case that we are pretty sure that the selector of our web element is not broken, changed or not visible by our web driver.

Things we will need to make this work:

First we will setup a couple of test to work on. I'll be using the pulper a web page design for testing practice. You can click on the link to set it up in case you want to use it, but any website can do the job for this tutorial.

import unittest
from pageobject.pagefactory import Factory

class TestHomePage(unittest.TestCase):

    def setUp(self):
        Factory.homepage.go_to_homepage()

    def test_pulp_homepage_title(self):
        assert "Pulp App Main Menu" == Factory.homepage.pulp_homepage_title.text

    def test_table_link(self):
        Factory.homepage.click_table_link()
        assert "Table of Books" == Factory.tablepage.table_page_title.text

    def test_list_link(self):
        Factory.homepage.click_link_list()
        assert "List of Books" == Factory.listpage.list_page_title.text

    def test_FAQs_link(self):
        Factory.homepage.click_link_faq()
        assert "FAQs" in Factory.faqpage.faq_page_title.text

Once we have this test going, lets add the allure package by importing it and adding allure title and step decorators.

Test class

import allure
import unittest
from pageobject.pagefactory import Factory

class TestHomePage(unittest.TestCase):

    def setUp(self):
        Factory.homepage.go_to_homepage()

    @allure.title("Test homepage title")
    def test_pulp_homepage_title(self):
        assert "Pulp App Main Menu" == Factory.homepage.pulp_homepage_title.text

Page Object class

    @allure.step("Click table link")
    def click_table_link(self):
        self.link_table.click()

    @allure.step("Click link list")
    def click_link_list(self):
        self.link_list.click()

    @web_driver
    @allure.step("Click link faq")
    def click_link_faq(self, driver):
        self.link_faq.click()
        logs = driver.get_log('browser')
        print(logs)

Now with everything set, our allure report should look something like this once we run the tests in our CLI.

$ pytest tests/ -v --alluredir=test-report/

Now I'm going to focus on our FAQs test. Notice that we have a function defined to click on the FAQs link, I've done this in order to capture the step on the allure report and to add the console logs to see what happens backstage.

Test class

    @allure.title("Test FAQs link")
    def test_FAQs_link(self):
        Factory.homepage.click_link_faq()
        assert "FAQs" in Factory.faqpage.faq_page_title.text

Page Object class

    @web_driver
    @allure.step("Click link faq")
    def click_link_faq(self, driver):
        self.link_faq.click()
        logs = driver.get_log('browser')
        print(logs)

In python we get the console logs through the get_log() function giving browser as an argument to get the browser JS logs that are displayed in the web console. There are more arguments that can be passed to our get_log() function but for this tutorial we will be focusing on this one.

After we run this test again in our allure report, we should get a section called "stdout" under the steps of this particular test.

And with this we finish the implementation of the console messages into our allure report.

With the previous implementation of web console message into our test report we get a couple of advantages to catch potential issues into our application.

Robust more complete test report: We can give to our developer a better perspective of the test results, a way to give a much better idea of the bug and it's solution.
Proactive testing: We get ahead of potential issues by getting Network messages, security warnings, JavaScript warnings and API messages.

With this we conclude our tutorial, I hope it is helpful to you and your team.

What is your ideal coding hour?

Manuel Mariñez — Fri, 10 Aug 2018 12:01:00 +0000

As a Software Quality Assurance by day and Software Engineering student at night, I have my difficulties trying to improve my coding skills during the day. Having a job, studying, (beautiful) girlfriend, family and friends, I sometimes struggle when I want to take a moment for me to code. While reading one of the posts here at Dev.to I found someone that recommended to wake up 1 hour earlier in the morning to do what i wanted, and that really helped... until I had so much homework to do that... well, I wanted to sleep at least 5 hours.

For motivation purposes I've been thinking on building a birthday webpage for my girlfriend's birthday during the #100DaysOfCode challenge that I recently get to know about

So I came up with this question for you all!, What is the best moment for you to code (you can add any ritual you do for preparation <('-'<) (>'-')> ).

Would it be possible to have Dev.To community meetup?

Manuel Mariñez — Thu, 09 Aug 2018 17:41:46 +0000

What are your Interview tips and tricks? Besides having knowledge

Manuel Mariñez — Tue, 31 Jul 2018 15:56:10 +0000

I'm curious on how you all manage is an interview. Tell me what's up ... for academical purposes

What is your experience with interviews under pressure?

Manuel Mariñez — Fri, 27 Jul 2018 13:34:14 +0000

And by under pressure I mean, getting to know you are having an interview the same day you send your Resume.

Which Android development book can you recommend?

Manuel Mariñez — Sun, 21 Jan 2018 23:04:20 +0000

How does dev.to post ranking works?

Manuel Mariñez — Thu, 11 Jan 2018 17:00:02 +0000