Programming interface testing — what is it, for what reason is it significant, and what is it that you really want to be familiar with it? First and generally essential, API represents Application Programming Interface. An API is a bunch of methods, capabilities, and different marks of access which an application, a working framework, a library and so on, makes accessible to developers to permit it to communicate with other programming. An API is a cycle like a UI, just rather than an easy to understand assortment of windows, discourse boxes, buttons, and menus, the API comprises of a bunch of direct programming connections, or calls, to bring down level capabilities and tasks. APIs can look imposing, yet they're intended to be available to prepared, educated software engineers.
Testing an API, API Automation testing is in many respects like testing software at the user-interface level, only instead of testing by means of standard user inputs and outputs, you use software to send calls to the API, get output, and log the system’s response. Depending on the testing environment, you may use a suite of prepared test applications, but very often, you will wind up writing code specifically to test the API. Regardless of the actual testing conditions, it is important to know what API test code should do.
Test Code: What it Should Do
Obviously, API test code ought to send a particular call to the API,
then result and log the normal and actual outcomes. It ought to likewise log
timing and some other significant measurements (except if they are all the more
handily caught by framework troubleshooting instruments), alongside line of
test code that was running when an API mistake happened. In the event that the
test code sets a memory cradle that is bigger than that necessary by the API,
you can then check out at the items in the support for improper overwriting
with respect to the API. The test code ought to catch all API yields delivered
throughout the test, utilizing variable which are at first set to unmistakable
qualities that wouldn't be created by the actual API; this makes it more
straightforward to perceive the API yields as you check the variable qualities
out.
What to Test For: Look for the
Ordinary
A lot of your testing ought to reflect conventional, anticipated utilization of the API — settling on an API decision as it would be commonly be finished, in a standard climate that doesn't put outrageous or uncommon weights on the framework. This completes two things:
1. Most clearly, it tests for issue emerging during regular use. Assuming a common utilization of an API call delivers a mistake under standard circumstances, that lets you know that there's a significant issue some place. Normal use testing permits you to get a large number of the most obviously worst bugs, as well as the majority of those which are probably going to emerge during practical use. The best and most essential testing is by and large that puts the framework through its ordinary speeds.
2. Regular use testing likewise sets a gauge for testing under
less commonplace, higher-stress conditions, and for more forceful, attempt
to-break-it testing. Assuming you test under surprising or high-stress
conditions first, without understanding the API's conduct under regular use
conditions, you can sit around attempting to find something that has all the
earmarks of being an extraordinary bug, when it really mirrors an issue with
essential usefulness. Assuming you start with conventional use testing, you can
disengage the issue all the more effectively, on the grounds that you limit the
quantity of likely wellsprings of mistake, and of strange ecological
circumstances which you want to consider.
What To Test For: Stressing the
System
High-stress test conditions provide you with important tests of
the API, which, like all software, must either function under difficult
conditions or fail gracefully, predictably, and according to specifications.
When you test-to-break, you find out what the software does at (or past) the
limits of ordinary operating conditions, as well as what it does when something
does go wrong.
High-stress test conditions furnish you with significant trial
of the API, which, similar to all product, under difficult conditions or fail
gracefully, typically, and as indicated by details. At the point when you
test-to-break, you figure out what the product does at (or past) the
restrictions of common working circumstances, as well as what it does when
something turns out badly. (These are the kind of issues which a decent
web-based course in programming improvement and testing can set you up for.)
What Should it Be Doing?
Assuming you realize that the API should play out a specific activity (trigger an occasion, update information, roll out an improvement to the vault, or set a banner), the tests ought to really take a look at the consequences of that activity. Does it happen when it should work out? What might be said about when it shouldn't work out? Also, are the outcomes what you could anticipate that they should be? Programming interface testing is regularly black-box testing, yet to the extent that you approach the consequences of the API's activities, they ought to be checked.
API Testing vs. Unit Testing
Note that API testing and unit testing are not the same
thing, although they are similar. Unit testing is done by the development team
to make sure that a particular unit of software functions as required; since it
is not black-box testing, it can’t accurately reflect use of that software in
the field. The job of the API tester is to test the software knowing only
what a user is likely to know. API testing also tests the unit as part of a
system, while unit testing typically tests the unit in relative isolation from
the rest of the system.
