OR
How to test an API?
Greetings folks!
Continuing our series on ‘How to create an API’, we are now digging little more deep. In this article, we will be talking about “API testing” & will discover how an app’s efficiency can be improved without dramatically rising QA costs.
For some of its features almost every application relies on third party APIs; from logging in with Facebook, to locating a place via Google Maps. But, unless their APIs are public, few teams spend enough time on API testing.
This can have serious repercussions.
But don’t worry, this guide will help you learn all about API testing that you need to know:
Areas of key concern-
- What is an API testing? Why is it important?
- How to do API testing?
- Types of API tests
- Automation
- API Testing tools
We’ll walk through each of these step by step. So, first let us begin with the very first question-
What Is An API Testing? Why Is It Necessary?
APIs or Application Programming Interfaces is what helps developers without having to design them from scratch to incorporate features from other apps into their own products.
This means that users can log in via Facebook to your event management app, locate a location they want on Google Maps and purchase a ticket via a booking service.
Everything can be done without leaving your app.
Why Is API Testing Necessary?
APIs help enhance a user’s experience and make it simpler for developers.
Different sections of an app may also be linked altogether. APIs glue various modules together in a micro service architecture, each with a separate database and interface. This implies that they are able to work independently and have greater uptime.
APIs reflect the middle layer of an application in a conventional three-tier architecture. They control the logic of the organization and link the other two layers (GUI and Database).
Testing was usually performed more on the GUI layer in the past. Testers could find bugs in its business logic by using the app’s GUI. But they had to wait for developers to finish the UI before testing. This delayed the process of testing and raised the cost of fixing bugs. Agile growth and automation of assessments make this method increasingly obsolete.
Now, by writing the APIs first, developers also build their applications. And they build a UI around it once the business logic is ready, creating the user interface.
You can find logic-related bugs much sooner and address them for a fraction of the cost by checking on the API layer.
Coming on to the second topic-
Test automation
This attribute enables you to increase the coverage of the test and keep the cost of QA low. But, it’s costly and time consuming to automate the GUI layer.
However,the testing scripts can be disrupted quickly by any changes to the app’s GUI.
The automated API scripts need less maintenance than interface tests, and can find bugs related to logic that can not be identified by unit tests.
Unfortunately, APIs present the most security threats of all the testable parts of your product. This also implies that in order to access user data or infect your servers with ransomware, attackers may easily exploit vulnerabilities in them.
Also, the cost is much higher than a buggy button or a form for such a weakness.
Anyway, it’s weaknesses are weigh too less in front of it’s incredible facilities…
Let me sum up the key advantages of API testing–
- Initial testing is much cheaper and this happens before the front-end is ready and address logic-related bugs.
- Improves your application’s security and performance;
- Uncovers bugs. If your API is public, it can damage other products and business processes.
- Re-uses Interface tests of the test data produced during API tests.
- Uncover problems with performance.
- Enhanced coverage of the test and its precision.
- Runs regression tests to ensure that the APIs and the systems using them have not been disabled by the recent modifications.
- Makes it simpler for your system to scale up (if all business rules are applied through APIs)
- Easily works with JavaScript , Python, PHP or any other JSON / XML supported languages.
And now comes the million dollar question! How to conduct API testing? What are its techniques?
How to do API testing?
API testing, in its simplest form, includes submitting API calls and verifying their replies.
A Pass/Fail status, or a call to other APIs, can return data in various formats of which JSON and XML are the most common ones.
You should know what types of requests they can make as well as their limitations before you begin testing your APIs.
These details can be found in the API paperwork or accessed directly from the developers.
You can easily ask the developers about the available endpoints, the HTTP verbs that you can use and their authorization limits, the appropriate fields and their validation limits, the Failed/Passed request response codes, and the error messages that are shown with failed requests.
You can only be sure that the API behaves as expected.
You can now set up an environment that allows you to make calls to the API and verify the answers.
Since APIs don’t have a GUI, testing them has to be done at the messaging level. You submit the requests directly, but (more on that later) there are a range of great resources that make API testing much simpler.
Check if everything works as it is supposed to, after entering the appropriate API parameters and configuring the DB and server by calling an API function.
Gladly! You’ll be able to start testing API after this.
However, you must understand all the API features clearly from the very beginning and have a well-defined testing scope.
Also, you need to write the test cases to ensure whether your API is up to the challenge.
- Input Parameters
- Expected answers
- Max response time
- Parsing Inputs
- Error Handling
- Right answer formatting
- Add the test script to each test case and execute it after each new compilation.
Hopefully, you have understood the technique behind API testing. Now, we will jump on to our next topic-
Types of API testing-
You may want to run various kinds of tests, depending on the nature of your tests. It could be worth running Security, Regression, Documentation, Reliability, in addition to Functional Tests, Negative, Innovation, and API Integration testing.
# 1 Functional Testing
Such checks ensure that the API is usable and can easily be implemented into other systems.
You may have to look at different user storeys (features from the user perspective) in functional testing and check whether they fulfil the requirements.
The goal is to make sure that all the potential situations and failures can be managed gracefully by the system.
First, as normal (the so-called “happy path”), you will have to go through the requests that users are likely to create when exploring your app.
Remember to add statements at this stage (e.g., the API should return a correct answer code).
You should pass on to the negative tests after doing the “happy path” tests. Their aim is to test how the API responds to all possible incorrect user inputs and to ensure graceful handling of any error.
They ensure that when anyone makes an incorrect input, hackers do not inject malicious scripts into the database and that the device does not crash.
This may include sending requests with incorrect endpoints / HTTP verbs / headers, making unauthorised API calls, or requesting non-existent information.
On three stages, functional testing can be done:
1. Contract tests
API agreements define how an API can interact, what resources you can request and how.
Your API is essentially worthless if your contract isn’t up to snuff.
Contract reviews make sure that the contract is written correctly and that the developers can use it.
2. Components tests
Now you’ll have to separately validate each method available in your API. Consumption of the API contract and generation of the clients to write component tests. Go through the test cases with positive and negative data and make requests one by one.
First, confirm the following:
- Well-structured questions and answers
- The API returns a suitable answer code (including an error when you go for it)
- Right error messages found in the body of a response
- The performance reaches the predicted baseline (by using regression / diff or making assertions)
- An anticipated response time is met by APIs
Perhaps, the most critical aspect of testing the API is component testing,. That’s because it can lay the foundations for all subsequent tests.
3. Scenario tests
Now you can integrate individual part experiments into different scenarios.
You can either look at the user storeys to understand in each specific scenario how API requests are made. Or else, via your UI, you can perform the necessary actions and catch the traffic that goes to the APIs.
Either way, when combining various API calls, scenario tests will expose some unexpected actions.
Users and developers might start using it in unintended ways after your API is released, which can lead to unexpected bugs. It is necessary, therefore, to write as many scenarios as possible with
Unexpected API call combinations.
You can re-use your component tests when new features are introduced to the framework to write scenarios for the added features.
# 2 Security Testing
Testing protection is vital to the success of any product, as your reputation can be easily undermined by an exploited vulnerability.
Quoting a real incident here- In the year 2017, Panera Bread’s webapp began leaking its users ‘ personal data. An unauthorised API endpoint made it possible for anyone to access the names, birthdates, addresses , phone numbers, and even credit card information of customers.
This incident has impacted at least 37 million individuals!
Therefore, you’ll have to validate access controls, user authentication, confidential data encryption and other security criteria to protect your app.
To discover the attack vectors and simulate hacker attacks in penetration tests, you can use the current test scenarios.
For example, you can combine your scenario tests with attempts at SQL injection or parameter fuzzing. As a consequence, any modifications triggered by these attacks will be uncovered by your security checks.
Automation Test
One of the reasons why API tests are run by so few teams is that they actually lack time. There’s always pressure to produce the product more quickly with Agile growth.
By investing in automation, the only way you can buy ample time for deep API testing is.
Each time developers make modifications to the API code, you can write test scripts once and have them run automatically. Testing process automation can reduce repeated activities, speed up testing and expand coverage.
By 2020, Smartbear predicts that the number of teams that automate > 50 percent of their API tests will increase by 30 percent (from 59 percent to 77 percent).
One of the fields where automation is most useful is API checking.
To maintain the security of your app, testing your API on an ongoing basis is important.
Automated tests make the full range of API tests easier to cover: functional, protection, positive, negative, edge cases, etc.
Sadly, 100 percent automation of API tests is not cost-effective.
When it comes to test automation, not all aspects of the scheme have equal priority. It is necessary to establish a strategy that will optimise the speed and ROI of growth.
You can add the most value by automating your product:
- Checking with Regression;
- Checking functional;
- Checking for performance;
- Multilingual assays;
- Testing errors; and
- Testing Powered by Results.
There are certain limitations to automated API testing, of course. To account for the multitude of use cases, security vulnerabilities, and potential integrations, you do need manual testers.
Usability, exploratory, and ad-hoc experiments are best left to humans for this purpose.
API testing tools
There are several tools that can assist you with checking your APIs.
What I prefer generally is – Postman(https://www.getpostman.com/) at MindK for manual testing and SoapUI for automated testing.
With more than 5 million testers using it daily, Postman is one of the most common resources for ad-hoc and exploratory research.
It is a basic REST client for Windows , Linux, or Mac that comes in the form of a Chromeextension(https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en) and desktop apps(https://www.getpostman.com/apps).
You can download them for free or subscribe ($10/18 per user per month) to Pro / Enterprise plans.
Postman does have an excellent (if somewhat slow) UI, unlike most similar tools. For testers who don’t want to get bogged down in coding, this makes it an excellent alternative.
Using Postman ‘s request creator, you can run API tests in isolation or generate sets of several tests.
it encourages simple exchange and communication of information.
For example, you can upload the test cases into a set to your knowledge base or package API calls and the expected responses and send them to your colleagues.
The tool also allows you to build Boolean tests, extract data from most modern web APIs, and even automate your tests. This is an important, but often confusing, function. Support for various environments ( e.g. creation, staging, etc.) and REST requests are among its neat features.
At the same time, it gets difficult to create a chain of actions in Postman and its WYSIWYG editor is far from great.
Nothing beats SoapUI(https://www.soapui.org/) if you need advanced automation or complex test scenarios.
It is the most common RESTful and SOAP API testing tool on the market. It comes in two formats: a free open-source version with full access to the source code and a Pro version (€595 / year) with some additional features (e.g. a SQL query builder, a form editor, and an XPath assertion wizard).
SoapUI is simple to learn (in just three days, you’ll pick it up).
It has a simple drag-and-drop interface that enables complex asynchronous tests to be generated easily and simplifies working with XML/JSON.
And if you need to go beyond the basic functionalities offered by the tool, such as configuring assertions or workflows, you may add these features to Groovy with your own code.
Data from databases, folders, or Excel can be loaded and the API interactions simulated in data-driven experiments.
With a few taps, SoapUI lets you bring efficiency and security evaluations into usable test cases.
Unfortunately, along with several other drawbacks, the free version lacks version control for the test scripts.
Concluding
……Aaand for API checking, that was pretty much it!
It’s time to take into account the advantages that your company can deliver toward its expenses.
- Will the future savings from bug fixes make up for the greater QA budget early on?
- Will your product add enough value to the improved test coverage and accuracy?
- Can you risk getting an unsafe app released?
- What is API testing? Can you now do an API testing all by yourself?
- What are the things I need to know about API testing?
- How do you perform API Testing?
- Why do we need API testing?
- What must be checked when performing API testing?
Folks, I believe that you have now found everything at one place that you needed to know and make a wise decision.
With our aim to cover almost each and everything on APIs, we at Ideatebox.com, have covered many topics on API earlier as well.
Check out our previous blogs on APIs, where we have tried to cover from the basics and also read our other technical blogs.
After all it’s all about being the master of the game! Isn’t it?
