I was applying for QA position and the SDET asked me this question:
How do you test a backend API?
In the interview.
I wasn't sure I answered it correctly. Just wondering if I can get some input from someone.
How you approach testing an API depends on a lot of things. Will the API be a public API that will be consumed by some external people/systems, or is it a part of a larger product's infrastructure? API is a general term that is sometimes used to describe anything from a COM interface, to a DLL or JAR you can reference, to a REST web service. Different approaches can be applied to testing these different things.
Often, if the API is part of your infrastructure you can test it pretty thoroughly through unit testing and the use of the product that consumes it.
If it is an externally consumable API then you need to be much more thorough because people could use it in different ways than you might expect and send data in much different formats, etc. It also usually needs to make sense, be intuitive and be well documented if it is externally consumable. You would also need to be more cautious about what is private and public, which may not be as important for an API that is only used by a single product.
Testing an API nearly always requires you to create some sort of consumer for testing purposes. You have to be able to interact with the API. The consumer is usually very simple - or an existing tool - and driven by automated test cases and not manual user interaction, although I have seen cases where people created a complex GUI app for testing purposes, and cases where the testing was still mostly manual through exercising that app.
If the API has dependencies, you may choose to mock those dependencies out so you can more thoroughly test all of those interactions and hit all of the positive and negative code paths. For instance, if the API interacts with a database and has the ability to create, modify and delete data you may want to mock the interaction with the database to more easily test cases such as deleting a record when it does not exist, or when it is the final record, or when it is unable to be deleted because of dependencies or even when the connection to the database is unavailable - you can then see how your API would handle these situations.
Choosing the tool is not the only decision you need to make when testing an API. As for any testing task you need to decide:
Now you probably have too little information to make definitive decisions that could satisfy you, your interviewer and stakeholders in a company. So, you could ask interviewer more questions about the nature of the backend API:
In general I think you should not expect a mocked front-end that's hooked up to the API calls for testing (however if you have one lucky you!). Instead, API functions are generally tested with unit and integration tests.
You'll need visibility into the API function calls themselves, so the testing will be white-box or at least grey-box. You should be provided with a Specifications Document which should list the signatures of each API function (the input parameters, the function or method name, and the return type). Then from the Spec Doc you'll write unit tests (in my case I prefer PHPUnit) to sanity check the input and returns for each API function, such as testing for boundary values and null inputs.
Lastly, if the API is part of a service you'll also want to to integration testing. These tests will be similar to "end to end" tests for the service where you test entire features that include calls to the API functions. You'll typically begin an integration test at a customer entry point, and verify the return as valid if it's correct for the customer. Personally I prefer Behat Mink or Cucumber for my feature tests.
That's my high level overview of how I would go about testing an API, hope that helps!
There are a couple of areas that you will have to understand and provide focus in testing.
There are a bunch of tools that you can use. Various chrome and firefox plugins will make your life easier when it comes to functional testing. SOAPUI is a pretty handy desktop client as well. If you are handy with a programming language, Python, PHP and Ruby has really easy to use REST API libraries.
Mocking is also a way to minimize dependencies, but this can get out of hand if not used properly. I've always liked using mocky.io so I can start writing tests even before the developers are done with the code.
Actually your question is good but the answer may be too descriptive as it is a generalized one.
We are in the domain of Online Media. The part of backend API testing that we used to do includes :
First of all we understood the functionality of the system where the role of API comes in.
Then we developed the end-to-end tests using JS and those API which are working in backend.
Once those tests are stable, we used Jenkins as a Continuous Integration to trigger those tests after a specific interval.
Then we used to observe the results in the output of Jenkins test. If the tests is pass we are green to go, but if it failed then we used to investigate that and then a bug can be filed on that.
In this way we used to test backend API.
In back end API testing, the tools you use depend on the type of API that needs to be tested.