What is API?
An API (Application Programming Interface) is
a collection of software functions and procedures, called API calls
that can be executed by other software applications.
What is API Testing?
API testing is mostly used for the system
which has collection of API that needs to be tested. The system could be
system software, application software or libraries.API testing is different
from other testing types as GUI is rarely involved in API Testing. Even if GUI is
not involved in API testing, you still need to setup initial environment,
invoke API with required set of parameters and then finally analyze the result.
Setting initial environment become complex because GUI is not involved. In case
of API, you need to have some way to make sure that system is ready for testing. This can be divided further in test environment
setup and application setup. Things like database should be configured,
server should be started are related to test environment setup. On the other
hand object should be created before calling non static member of the class
falls under application specific setup.
Initial condition in API testing also involves creating conditions under which
API will be called. Probably, API can
be called directly or it can be called because of some event or in response
of some exception.
Test Cases for API Testing:
The test cases on API testing are based on the output.
•Return value based on input condition
Relatively simple to test as input can be defined and results can
be validated. Example: It is very easy to write test cases for int add(int a,
int b) kind of API. You can pass different combinations of int a and int b and
can validate these against known results.
•Does not return anything
Behavior of API on the system to be checked when there is no
return value.
Example: A test case to
delete(ListElement) function will probably require to validate
size of the list or absence of list element in the list.
•Trigger some other API/event/interrupt
The output of an API if triggers some event or raises some
interrupt, then those events and interrupt listeners should be tracked. The
test suite should call appropriate API and declarations should be on
the interrupts and listener.
•Update data structure
This category is also similar to the API category which does
not return anything. Updating data structure will have some effect on
the system and that should be validated.
•Modify certain resources
If API call is modifies some resources, for example makes update
on some database, changes registry, kills some processes etc, then it should be
validated by accessing the respective resources.
API Testing vs. Unit Testing: What’s the difference?
1. API testing is not Unit testing.
Unit testing is owned by development team and API by QE team.API is mostly black
box testing where as unit testing is essentially white box testing.
2. Both API-testing and unit-testing target the code-level , hence similar tools can be used for both activities. There are several open source tools
available for API testing and a few of them are Webinject, Junit,
XMLUNIT, HttpUnit, ANT etc.
3. API testing process involves testing the methods of .NET, JAVA,
J2EE APIs for any valid, invalid, and inappropriate inputs, and also testing
the APIs on Application servers.
4. Unit testing activity is owned by the
development team; and the developers are expected to build Unit
tests for each of their code modules (these
are typically classes, functions, stored
procedures, or some other ‘atomic’ unit of code), and to ensure that each
module passes its unit tests before the code
is included in a build. API testing, on the other hand, is
owned by the QE team, a staff other than the author of the code. API tests are
often run after the build is ready, and it
is common that the authors of the tests do not have access to the source code;
they essentially create black box tests against an API rather than the
traditional GUI.
5. Another key difference between API
and Unit testing lies in the Test Case design. Unit tests are
typically designed to verify that each unit in isolation performs as it should.
The scope of unit testing often does not consider the
system-level interactions of the various units. Whereas, API testing,
are designed to consider the ‘full’ functionality of the system,
as it will be used by the end users. This means that API tests must be far more extensive than unit tests, and take intoconsideration the sorts of ‘scenarios’ that the API will be used for, which typically involveinteractions between
several different modules within the application.
API Testing Approach
An approach to test the Product that contains an API.
Step I:
Understand that API Testing is a testing
activity that requires some coding and is usually beyond the scope of what developers
are expected to do. Testing team should own this activity.
Step II:
Traditional testing techniques such as equivalence classes and
boundary analysis are also applicable to API
Testing, so even if you are not too comfortable with coding, you can still design
good API tests.
Step III:
It is almost impossible to test all possible
scenarios that are possible to use with your API. Hence, focus on the
most likely scenarios, and also apply techniques like Soap Opera Testing and Forced Error
Testing using different data types and size to maximize the test coverage. Main
Challenges of API Testing can be divided into following categories.
• Parameter Selection
• Parameter combination
• Call sequencing
API Framework
The framework is more or less
self-explanatory. The purpose of the config file is to hold all the configurable components
and their values for a particular test
run. As a follow through, the automated test cases should be
represented in a ‘parse-able’ format in the config file. The script should be highly ‘configurable’. In the case of API Testing, it is not necessary to test every API in
every test run ( the number of API’s that are tested will
lessen as testing progresses). Hence the config file should have sections which detail which all API’s are “activated” for
the particular run. Based on this, the test cases should be picked up.
Since inserting the automation test case
parameters into config file can be a tedious activity, it
should be designed in such a way that the test case can be left static with a
mechanism of ‘activating’ and ‘deactivating’ them.
Definitions:
Soap Opera Testing:
Soap opera tests exaggerate and complicate scenarios in the way
that television soap operas exaggerate and complicate real life.
Forced Error Testing:
Forced error testing is nothing but mutation testing. It is
process of inducing error /changes to the application to find how application
is working. The forced-error test (FET) consists of negative test cases that are designed to force a program
into error conditions. A list of all error messages that the program
issues should be generated. The list is used as a baseline for developing
test cases.
Software Functions and Procedures:
Functions and procedures are the foundations of programming. They
provide the structure to organize the program into logical units that can
manage the various activities needed for a program.
Functions
There are two basic types of functions:
Built-in
—these are built into the programming environment and do things
such as opening and closing files, printing, writing, and converting variables
(e.g., text to numbers, singles to integers, etc.).
Application/user-specific
—depending on what the program needs, you can build functions and procedures
using built-in functions and procedures and variables.
Procedures
Procedures are used to perform a series of tasks. They usually
include other procedures and functions within the program. Procedures typically do not return
a value; they are simply executed and return
control to the calling procedure or subroutine.
Procedures in Visual Basic are called "Subroutines," often
"Sub" for short. In JavaScript, "Functions" are used as
procedures (they simply return no or null values to whatever called them).
Source: www.scribd.com/doc/9808382/Introduction-to-API-Testing
