nonstopio
Published in

nonstopio

API Testing — Mocking API Response & Request

API

Hello Readers,

Automated testing is a great way to ensure the quality of your software. It helps you identify what behaviors you expect to see, and gives you an explicit statement about what went wrong if you encounter a bug. In today’s world, the role of communication is important in this journey. Good dialogue attracts viewers. Security also has to be tight where there is more attraction because where there are more spectators things are more likely to go bad. Today we are going to learn more about API testing. But before that, I would like to suggest you read my previous blog on API testing so that you can understand our today’s discussion better.

We are going to know about how to mock API through cypress and why it is important to test API and why we should mock API.

Mocking APIs helps in situations where we only have the front-end of the application or we are dependent on third-party APIs. Mocking enables one to decouple the back end from the front end which results in faster execution of tests. Frontend developers and backend developers can work in parallel, hence fast development.

Why should mock API — Advantages

Suppose you are testing a web application and you want to test a subscription search for books in that web application. You will need multiple accounts to check each scenario and this can be a very time-consuming task. In some cases, due to the unavailability of data, some scenarios cannot be checked. A mocking response is a good way to check the above scenario without any bar.

UI/UX developers can start only the required backend mock APIs

  • The frontend can act as a standalone application during development without any backend API dependencies.
  • Enable offline development
  • Easy to demo
  • The mock API can easily be replaced with the Real API once it’s ready.

What should be mocked

Now that you have understood API Mocking’s benefits let’s find out some common modules and operations suitable for mocking.

  • CRUD Operations — Create, Read, Update, and Delete operations in the application’s main user flows.
  • Authentication and Authorization Flow
  • Pagination
  • Search/Sort
  • Error Handling — e.g., Timeouts, delays, validations, etc.
  • File Download

Mock the Response and Request by cypress tool

Now, we will see how to mock an API through Cypress. Cypress is a promising tool that continues to grow in the automation industry and this tool is giving us many amazing things.

cy.request({method: 'GET',url: "https://reqres.in/api/users?page=2",headers: {'Content-Type': "application/json"},}).then((response) => {cy.log(JSON.stringify(response));expect(response.status).to.eq(200);

After execution the API above, you will get a list of all the users. Now, if you want to check what happens when you get only one, zero, or multiple records in the search result, you have to register a new user and check each time. In the API mocking, you can mock the response and check how the product behaves if you find specific users in the response.

cy.intercept({
method: 'GET',
url: "https://reqres.in/api/users?page=2",
},
{
statusCode:200,
body:{
"page": 2,
"per_page": 6,
"total": 1,
"total_pages": 2,
"data": [
{
"id": 7,
"email": "michael.lawson@reqres.in",
"first_name": "Michael",
"last_name": "Lawson",
"avatar": "https://reqres.in/img/faces/7-image.jpg"
},

In the mocking response, you have to send your response in the original API structure with the intercept method and you can check all scenarios without original data.

Now, Sometimes you run the API and you got the response but do you verify that the received response from API is correct or not. Cypress is the tool that can help you in the same.

Suppose you are logged in to the bank’s website to check your bank account details. After checking the details you tried to log in by updating the username in the URL to check your other account details and if that attempt is successful then all your bank accounts are in danger. This is the best example to check security testing by API in cypress. To make sure your product will not hack easily and protect your data from hackers you need to make efforts.

cy.intercept('GET','https://apnabank.com/SingIn/GetAccount.php?AuthorName=shetty',
(req)=>
{
req.url="https://apanabank.com/SingIn/GetAccount.php?AuthorName=malhotra"

req.continue((res)=>
{
// expect(res.statusCode).to.equal(403)
})
}
).as("dummyUrl")

cy.get("button[class='btn btn-primary']").click()
cy.wait('@dummyUrl')

})

})

In the above example, you are logged in Shetty account of Apna bank. later, after checking account details you just updated the user name to Malhotra and executed the URL. If you got success in your case please contact your bank today.

If your web application is anything like the one we build and support, it depends on external data sources from other teams, both within and outside of our organization, which means we can’t always rely on that data (especially when it comes to non-production data) to be clean, accurate, or — in some cases, even in existence. This is why, when it comes to writing and running our end-to-end (e2e) tests (which are the tests that depend on external data), we mock (or “stub”) those API calls instead of hoping the stars align and no one else has changed that same data to suit their needs.

Unreliable lower life cycle data, outside of the control of your development team, is no reason to keep new code from being merged in and deployed to production. But the old adage “It works on my machine” 🤷‍♀ is also not a valid justification because who knows that the same will hold true when deployed somewhere besides a local development laptop.

Conclusion

Testing, although it may not be fun to write, helps ensure that all parts of a web application continue to function as they should, even as new features are added. End-to-end tests, one of the myriads of testing types available test an application’s flow as an actual user would: toggling buttons, clicking drop downs, checking whether items are visible or not on a page, etc.

But although tests (and good test coverage) are a critical part of my development team’s process, the data we depend on from other teams, outside of our control, is not always the most reliable. For this reason, we choose to mock our Cypress HTTP calls to those outside services in our e2es to ensure that bad test data isn’t the thing holding us back from adding new functionality our users want. And trust me, it’s saved us a ton of extra time and headaches trying to debug why things aren’t working right.

Thanks for reading. I hope this article will help you in your journey of automation and help you understand the Mock API, and security testing.

Share your valuable feedback in a comment.

Just Kidding………

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store