Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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.

Thank you.

share|improve this question
1  
The "backend" adjective is misleading, and the question overall is very open-ended. Can you be more specific? –  Bj Rollison Sep 5 '13 at 6:00
1  
@Aziz - how did you answer? –  Joe Strazzere Sep 5 '13 at 12:44
    
Have you tagged the question with "manual-testing" intentionally? Do you expect backend APIs to be tested manually? Certainly that's possible to manually explore API behavior with GUI tools like SoapUI but is rather uncommon practice in a long run. –  dzieciou Sep 5 '13 at 19:59
    
@Bj Rollison, why do you think "backend" adjective is misleading? To me it narrows the context a bit, implying there is also a GUI frontend part of the app. There are also apps with no GUI at all, where API can be considered kind of API. –  dzieciou Sep 7 '13 at 15:46
    
@dzieciou - I assume you are referring to a headless agent where there is not GUI (graphical user interface) but there is still (usu.) an interface to the API. –  Bj Rollison Sep 8 '13 at 5:42
add comment

4 Answers

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 create an application to interact with the API. The application is usually very simple 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.

share|improve this answer
    
Thank you guys so very much. I really do appreciate your all your help. –  Aziz Sep 6 '13 at 3:43
add comment

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!

share|improve this answer
    
Thanks so much for your input. So to clarify, for integration testing one can use manual / automated (Behat Min or Cucumber) UI testing right? –  Aziz Sep 5 '13 at 16:32
    
Integration or feature tests will usually have some sort of interface available since ideally a feature should be a customer deliverable. So UI tests could be done using a webdriver for example like Selenium. But backend API in the original question implies that there's no interface available so testing the functions directly is necessary. –  Francis Sep 5 '13 at 17:34
add comment

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:

  1. What aspects of the program are you testing? What application features do you want to cover with API testing? Are you going to verify some stateful scenarios (e.g. when user is logged in)? Or maybe you want to verify how an API behaves for different configurations?
  2. What types of problems are you looking for? What part of application is most probable to fail? In what conditions? Are there functional or performance problem? This should help you understand what are scenarios that are easier/faster/cheaper to test with API instead of using frontend.
  3. How will you tell whether a test passed or failed? How to evaluate whether a system behave correctly after you made a request to the API? Will you evaluate only explicit API response (e.g. it confirms it has sent an email) or you want also to verify whether it actual did what it says (the email was actually sent your account)? Furthermore, how do you know what is an expected result for a given API call?
  4. What tasks, specifically, will you do? Depending on the directions taken in the previous answers, you can think of exploratory testing, when you just explore API behaviour, hunt for some particular bugs, or define thorough test cases in advance? Whether you perform the manually or you automate them? Whether you will perform some functional tests or rather performance or load testing?
  5. Who will do the testing? Will you be the one who will test API, or maybe you will have some people who will write customer applications to test different parts of the API? How much do you know about API related technologies to automate the tests? The answer will help you to choose the right tools to test.

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:

  • Who or what is the consumer of the API? Front-end tier being a part of SUT or an external client app? Maybe there is no frontend? Is this a public API or internal used only by a few people? The answer will tell you how thoroughly you should test the API?
  • What scenarios have been covered in end-to-end test with frontend included and what scenarios have not been? What are the challenges when testing via frontend? The answers will guide you to the type of scenarios you should cover and those you should not. For instance, if invalid input validation functionality is implemented only on the backend side, this is one area to stress in API tests.
  • What technology is used to expose an API? SOAP or REST Web service, RMI, CORBA, command-line, COM, etc. The answer will imply what kind of tool or programming language you should use to implement test cases.
  • Is there some formal specification for API? Or you need to guess an expected behavior somehow, e.g., from specification for UI?
  • Does the backend talks to other components in the system? To database? Does it contacts external services?
share|improve this answer
add comment

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.

share|improve this answer
    
Two last points are not specific for testing backend API. You can use CI and investigate failures for any automated tests. –  dzieciou Sep 8 '13 at 19:53
    
@dzieciou : Yes that's correct. Still I have mentioned them to have a complete flow of the testing. You can use other ways for CI. –  talktokets Sep 9 '13 at 16:48
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.