APIs carry the majority of any application’s functional and business logic, and the pace at which they undergo changes and additions, it becomes an avoidable task to test and protect them against failures and vulnerabilities. HyperTest uses network traffic to automatically generate tests cases that also update themselves eliminating the need to write any tests on your own. The simple test design principle, compares the version under test with the stable version, at the same time, to generate all assertions dynamically, removing the need to think or write assertions at all. HyperTest is able to also test flows that are otherwise difficult to test with the help of Middleware.
Why Middleware?
HyperTest generates end to end tests from the network traffic of any application. This means we record or monitor all incoming requests with the request data which eliminates the need to maintain test data on its own.
The request data we capture from requests work as the actual test data, and when these auto-generated tests are executed on 2 versions of the application, stable and test, the requests are played exactly in the same sequence with the test data intact.
But sometimes the request data that we record from application traffic cannot be exactly used as is to test the flow because for certain kinds of requests, data becomes unusable across successive requests, for example testing a sign-up flow or other non-idempotent flows.
Hence, HyperTest provides a way to programmatically alter the traffic (request data) captured via a network so the non-idempotent flows can be tested without any hassle.
What are some of the common use cases of Middleware?
2-factor authentication and login via OTP The username/password, fingerprint, or Face ID that a user provides to validate their account is usually the initial layer of 2FA. On top of the first layer of authentication, there is a second layer of authentication which may be through an email with a confirmation link, an SMS with a One-Time Password (OTP), or an installed app.
Let’s take the example of OTPs in two-factor authentication. When a user logs in, they key in their email address and password, after which the application sends an OTP to the user. Now it’s important to note that at this point, the access token for this has not been generated yet. The user enters the OTP received and completes the login. This is where the access token is generated, and every transaction hence carries that access token.
However, since the login process did not have an access token, it makes the flow difficult to test. HyperTest uses middleware to solve this problem. It generates a new access token that replaces the old or current access token from every transaction, including the login. This makes the entire flow testable, including the login process.
Loan/order processing example or testing a state machine
To test a ‘traditional’ state machine, i.e. one where the output code is mixed with the state transition code, typically you would have to run the application, stimulate it somehow, and look for secondary evidence that the state machine is working. As we all know, the loan processing state machine is one of the most complex structures in testing. Let’s understand this process. When you apply for a loan, a new loan is created and sent to the customer. A loan agent is assigned to the respective loan and customer. Then, the agent checks in at the customer’s residence and fills out the loan requirements. They upload collateral proofs like images, videos of documents, ornaments etc. and complete the KYC. The Office Admin verifies proofs and approves or rejects the loan based on the due diligence provided. Finally, the Agent collects collateral and if the loan is approved, the money is sent to the customer’s account.
What makes this flow difficult to test is that we can’t reuse the same loan ID twice, and we can’t reuse access tokens. What HyperTest does is that it automatically checks each API calls made, including all idempotent and non-idempotent methods like the PUT and POST calls made for each of the requests identified in the flow of loan processing, starting from the loan application, through to the last step when the amount is credited to the applicant. HyperTest uses the existing traffic and user flow to test your application and identify regressions that you may then flag as issues to the engineering team.
Session Differentiation
When a user logs in, they usually key in their email address, user name, mobile number or other unique IDs. This unique identifier can be located in the query parameters, path, body etc of the API. In order to differentiate on the basis of user IDs, for example, HyperTest exposes a middleware which allows you to check for the User ID in the query, path or wherever it may be located in the API. It would be the same for other unique identifiers such as email, mobile number etc. For instance, to check an order service, you can differentiate on the basis of order ID, for a loan service, check the loan ID and so on. You have programmatic access to find this key in all placements to extract the value and differentiate the session. So, if there are ten APIs where the user ID is in separate placements, all of them would be grouped into a single session, regardless of where it is placed.
Grouping login requests into the same test case
By default, users need to key in a unique identifier in order to log into an application. It could be an email ID, phone number, user ID, etc, which can be used as a common property for grouping. HyperTest uses a middleware to differentiate its test cases (or sessions) based on any such property or parameter that is common among all the requests part of the same test case, but clearly different from the test case (or session) of a different user flow. But how do we group requests or flow of the same user in a single test case? When the user logs in to their account, an auth token is generated, which is unique for each user. This auth token is used in all the following requests by the user post login. So, when we use the generated auth token. HyperTest uses it as an identifier for that user and links all the subsequent requests of that user in the same test case. Job done!
Today’s market has grown more dynamic, necessitating the integration of formerly separate applications and an emphasis on enterprise-wide information systems. Making new applications function in tandem with legacy programmes is the goal of this application and system integration activity. This is where middleware comes in handy, allowing businesses to keep their multiple programmes in sync and eliminate the need to update legacy software. The need for automation grows as firms speed their digital transformations, in which middleware plays a significant role. Moving toward increased automation in business and IT operations should begin with small, measurable projects that you can then scale and optimise for other processes and portions of your company. If you’d like to understand how HyperTest can help you automate your testing process, schedule a demo with us and we’ll get straight to it!