Authors
Feature Friday – Dive Into API to Database Testing and Validation
Budgeting, a very interesting concept that some are privy to, comes down to the recording and maintenance of all monetary transactions. But all budgeters know and fear the moment that their payments don’t match their data logs. They are forced into hours on the phone with the bank, often to realize it was a relevant purchase that was improperly logged, leaving no one to blame but yourself. APIs and databases work almost identically except instead of transaction history the transferring and logging is of any essential application data. This week’s feature Friday is brought to you by Daniel and Joyal where we will dive into Qyrus’ API to database testing and validation feature.
Tell us more about the API to DB feature offered by Qyrus, its use cases, and impact on testing and QA processes?
Daniel:
API to DB is used to validate an API’s behavior whose job is to save or manipulate data to a database. The user maps values in their APIs request body to a column in their database and creates assertions to ensure that the data being sent by the API is properly saved or altered in their database.
Joyal:
Similar to a logbook of transactions, your database is your central point for data logging and management. Therefore, it becomes essential to test API to DB processes ensuring that the request body passed into an API is properly saved in the database and the right transformations, if required, have been done on the data before it was saved.
Daniel:
In essence, this feature attempts to answer the question, “How can I be sure that my API properly saved the data into my database?”
A very interesting feature, API to DB is sure to make an impact on the testing process. With a feature like this, testing databases becomes much easier and seamless. We asked Daniel and Joyal:
What is the API to DB feature’s overall impact on the testing process?
Daniel:
API test can be a little more technical than things like Web and Mobile application testing. It is much easier for tests to fail simply because tests were not set up properly. As such, we have focused on simplifying the configurations required in this form of testing as well as providing clear feedback and visualizations to assist the user in the building of these tests. One example would be our JSON tree mapping tool which provides a visual representation of the API’s request body and is intractable. The user only needs to click on the node they are looking for in order to extract the JSON path they want to map to a database.
Joyal:
Furthermore, we see it solving multiple problems as you are ensuring any logic that is executed after the API is called is working properly as well as the API itself. So, you are testing two different entities using the same test.
Daniel:
Yes, Joyal, and that’s exactly the value, keep it simple but comprehensive.
As we’ve heard from Daniel, we want to keep it simple. Complex testing processes can lead to more errors. Having to switch from one application to another just to perform a simple task is ridiculous. The team at Qyrus sought to tie it all together.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Joyal:
So, we have seen prerequisite API test options but there are just a few differentiating factors. Tests on Qyrus include in-depth reporting and the ability to dynamically use responses across API tests upon execution of the prerequisite API.
Daniel:
And it’s no secret that there are multiple ways to solve this problem without Qyrus. The automated way would require knowledge of a couple of different libraries and combining them to create a multi-step process. The manual way would be akin to something like calling in API in Postman, opening up something like MySQL workbench to make a database query, and then visually confirming that what you entered into the API’s request body was saved into the database correctly. Believe it or not, but this manual workflow is what we often hear developers are doing today.
Database testing has historically been a complex task that only those with high knowledge of the database would be able to properly test it. With the introduction of API to DB testing in Qyrus, we have seen that the process has been simplified to the point where even non-technical people have a use for it!
How might the API to DB feature help testers, developers, and business technologists? What value can they bring?
Daniel:
Great question… we often find that a tester would first use functional testing in the API service to ensure that the API is “behaving” the way they want it to by providing adequate assertions in their functional test. Once they know the API is behaving as expected, they then create database assertions to ensure that the API is properly storing the data to their database. Testers would use this to ensure proper communication between their APIs and their databases.
Joyal:
Developers could use this to make sure the API itself is functioning and the logic that is executed after the API is called is working properly. Furthermore, verifying the final output in the database, ensuring database functionality. Developers can run these test executions during sprints and through CI pipelines to ensure existing data processing functionality upon new builds.
Daniel:
With robust reporting and easy to make assertions, this feature stands as a great transition for business technologists and analysts to further understand the inner workings of their application. Following the data transfer and storage process is made simple with robust reporting while staying in the loop is even easier with collaborative reporting options. With a codeless approach, non-technical specialists can go as far as building out test scripts to ensure application and database synchronization and functionality.
All of this being said, we know that this feature will have an impact on testing overall. The ramifications of this process being simplified means that certain routines or testing processes will no longer be as lengthy or time-consuming. We asked:
How do you see Qyrus’ API to DB feature impacting day-to-day operations across organizations?
Joyal:
The first thing we see is the feature mitigates redundancies in testing operations. With a prerequisite API, the tester will no longer need to manually enter in pre-request credentials for every pre-request dependent API call. Within the prerequisite API, the tester enters the pre-request credentials once and the API will always run before a request execution takes place.
Daniel:
Correct, and after a prerequisite API is created and executed, a user is able to dynamically reuse the response body across the entire project.
Joyal:
We also note that this feature offers you more depth in testing. You are not just testing whether you got the expected status code or response body from an API call anymore. You are making sure any transformation that is done on the request body is properly reflected on the data that is saved in the database.
Daniel:
With further developments coming including more database options and allowing users to add logic or code snippets into prerequisite requests for specific header input requirements we truly see this feature making an impact on testing at a day to day, script to script level.
That’s all folks! Thanks for joining us this week for Feature Friday. The team here at Qyrus hopes you enjoy the weekend, the weather, and stop to smell the roses every once and a while! As Spring rounds the corner, dreams of summer are just right behind it.
