Content

• What is an API?
  
  
  • API - feature set
  • How is the feature set compiled
  • What does the word "interface"
• How the API is called
  
  
  • API call directly
  • Indirect API call
• What does API Testing mean?
• Summary

The word "API" appears in vacancies even for beginner testers. Either REST API, then SOAP API, then just an API. What kind of beast is this? Let's figure it out!



“Why do I need this?” I'm actually testing the web! Now, if I go into automation, then yes ... Well, they’re also testing it in enterprise, I heard ...



And no! It’s good for any tester to know about the API. Because on it the systems interact with each other. And you see this interaction every day even on the simplest and seediest sites.

Any payment goes through the payment system API. Bought a movie ticket? A t-shirt in an online store? A book? As soon as you click "pay", the site connects you to the payment system.

But even if you don’t have integration with other systems, you still have an API! Because the system inside itself also communicates via api. And while the front developer is heavily sawing the GUI (graphical interface), you can:

• miss waiting;
• check API work logic

Of course, I am for the second option! So let's understand what the API is.

What is an API?

API (Application programming interface) is a contract that a program provides. "I can be contacted this way and that, I undertake to do this and that."



If translated into Russian, it would be the word “contract”. An agreement between two parties, as an agreement to purchase a car:

• my responsibility is to pay such an amount
• the seller’s duty is to give the car.

You can translate, yes. But no one does that ¯ \ _ (ツ) _ / ¯



Everyone uses the word "contract." So accepted. In addition, this word is included in the name of the development style:

• Code first - first we write the code, then we generate a contract on it
• Contract first - first create a contract, then write or generate code on it (in this article I will talk about this style)

We don’t say “a contract for the sale of a car”? So the developers do not say "contract." Tacit agreement.

API - feature set

When you buy a car, you draw up a contract in which you prescribe all the points that are important to you. Similarly, contracts should be drawn up between programs. They indicate how one or another program can be accessed.



Accordingly, the API answers the question “How can I contact my system?”, And includes:

• the operation itself that we can perform
• input data
• output data (data content or error message).

Here you can tell me:



- Hmm, wait. The operation, the input data, the output data - somehow all this is very much like a function description!



If you have ever come across development or just learned a programming language, you probably know what a function is. In fact, we have input data, there is output data, and some magic that converts one into another.



And yes! You will be right that the definitions are similar. Why? Yes, because the API is a set of functions. This may be one function, or may be many.

How is the feature set compiled

Yes, no matter how. As the developer wants, it will group. For example, you can group the API by functionality. I.e:

• Separate API for entering the system, where registration and authorization will be;
• separate API for reporting - report 1, report 2, report 3 ... report N. For different reports we have different formulas = different functions. And we all collect them into one set, api for reporting.
• Separate API payment systems - for work with each bank its own function.
• ...

You can not group at all, but make one common API.



One common API can be made, and the rest can be made to order. If you have a boxed product, then it usually includes a set of standard features. And any Wishlist customers are made separately.







It turns out that in our system there are several different APIs, for each of which we have a contract written. Each contract clearly spells out what operations can be performed, what functions will be there







And of course, functions can be reused. That is, the same function can be included in different sets, in different api. Nobody forbids this.







It turns out that the developer comes up with what kind of API he will have. It either does the general, or distributes according to the functionality or some of its own criteria, and adds the set of functions that it needs to each api.

What does the word "interface"

- Wait a minute, Olya! You yourself wrote above that the API is an Application programming interface. Why are you then talking about the contract, although there is the word interface?

Yes, because in programming a contract is the interface. In the classic description of OOP (Object Oriented Programming) there are 3 whales:

1. Encapsulation
2. Inheritance
3. Polymorphism

Encapsulation is when we hide the implementation. For the user, everything is easy and clear. I clicked on a button - I received a report. And how it works from the inside out - he doesn't care. Which database is hidden under the hood? Oracle? MySQL? What programming language is the program written in? How exactly is the code organized? Not the point. The program provides an interface, and it uses it.



Not always the program provides a graphical interface. It can be a SOAP, a REST interface, or another API. To use this interface, you must understand:

• what to enter;
• what happens at the exit;
• what exceptions need to be handled.

Users work with the GUI - graphical user interface . Programs work with API - Application programming interface . They do not need graphics, only a contract.

How the API is called

You can call api either directly or indirectly.



Directly:

1. The system calls functions within itself
2. The system calls another system's method
3. Man calls a method
4. Autotests pull methods

Indirectly:

1. User works with GUI

API call directly

1. The system calls functions within itself

Different parts of the program somehow communicate with each other. They do this at the program level, that is, at the API level!



This is the easiest way to use, because the author of the API that is being called is the developer. And he is his consumer! So, there are no problems with irrelevant documentation =)



Just kidding, there are always problems with documentation. Just in this case, the documentation will be comments in the code. But they, alas, are also irrelevant. Either the developers are different, or one, but I already forgot how I did the original api and how it should work ...

2. The system calls the method of another system

But this is a typical case that testers test in integrators. Or testers who test the integration of their system with someone else’s.



One system pulls through api some method of another system. She may try to get data from another system. Or vice versa, send data to this system.

Suppose I decided to connect the prompts from Dadata to my online store, so that the user easily entered the delivery address.



I am connecting API hints. And now, when the user begins to enter the address on my site, he sees the prompts from Dadata . How it turns out:

• He enters a letter on my website
• My site sends a request at API Dadat hints
• Dadata returns the answer
• My site processes it and displays the result to the user.

There are so many steps! And so for each character entered. The user does not see this interaction, but it is.

And, of course, do not forget about the case when we develop the API method. Which can only be called through SOAP, it is nowhere to be found in the interface. What the Customer ordered, we did ¯ \ _ (ツ) _ / ¯

An example can be found in Users. The MagicSearch method is based on real events. Although I must admit, in the original logic was even more sophisticated, I adjusted it to my site.



But the trick here is that in the system itself in the user interface there is only a normal search, just an input line. Well, maybe a couple of filters. But integration needed a whole bunch of additional features, which was done through the SOAP method.



Super-search functionality is available only by API, the user in the interface does not feel it.

In this case, you usually have TK, according to which the API method works. Your task is to check it. A typical task of a tester, just add the API testing features to standard test design tests, and it’s all about the hat!



(what exactly needs to be tested in the API - I will tell in a separate article a little later)

3. The person calls the method

The reasons are different:

1. To speed up work
2. To localize the bug (where is the problem? On the server or client?)
3. To test logic without edge spins

If the system provides an API, it is usually easier to yank it than to do the same through a graphical interface. Moreover, the API call can be saved in the tool. Once saved - you apply at any base, even if it is cleaned 10 times a day.

For an example we again go to Users . If we want to create a user, we need to fill in a lot of fields!







Of course, this can be done using special plugins such as Form Filler . But what if you need adequate test data for your system? And in Russian?



Filling in the fields manually is sad and depressing! And if you need to repeat this every week or day on a clean test base - generally a nightmare. This is immediately the first priority for automation of routine actions.



And in this case, the role of the automation performs ... Postman. A user can be created through a CreateUser REST request. Once registered normal “like real” data, every time we use it. Profit!



Instead of manually filling out the form (1 minute of thoughtlessly filling the fields with the values ​​“lprulpk”), we get 1 second of pressing the “Send” button. In this case, the values ​​will be much more adequate.



And in postman you can make a separate folder for preparing the test base, cram a dozen requests there. And now, at any base, in a couple of seconds you get as much data as you would manually drive for hours!

If you find a bug and don’t understand who to hang it on - front-end or back-end developer, remove all unnecessary. Call the method without a graphical interface. And you can test the program logic until the interface is ready or broken.

4. Autotests pull methods

There is a typical automation pyramid:

• GUI tests are an honest test, "how the user would do it."
• API tests - we go down one level, throwing away the excess.
• Unit tests - tests for a single function

The word API hints at what will be used in the tests ツ

Let's say we have:

• operation : report download;
• at the input : data from manual or automatic adjustments or from some other places;
• output : a report built according to certain rules

Report building rules:

• Cell 1 : X - Y
• Cell 2 : Z * 6
• ...

GUI tests are an honest test, the robot does everything that the user would do. It opens the browser, pokes on the buttons ... But if something falls, you will figure out where exactly for a long time.



API tests are the same, only without a browser. We simply feed the input and check the output. For example, you can enter the final answer in Excel, and let the robot reconcile it, is the data filled in correctly? Locating the problem becomes easier.



Unit tests are when we test each function separately. We separately look at the calculation for cell 1, separately for cell 2, and so on. Such tests are most quickly chased and bugs are easy to localize on them.

Indirect API call

When the user works with the GUI, in fact, he also works with the API. He simply does not know about it, he simply does not need it.



That is, when the user opens the system and tries to download the report, it does not matter how the system works, what kind of magic is inside. He has a button “download report”, which he clicks on. The user works through the GUI (graphical user interface).







But in fact, under this graphical user interface is an API. And when the user clicks on the button, the button calls the report construction function.







And the report building function can already call 10 different other functions, if it is needed.



And now the user sees a ready-made report in front of him. He called a complex API without even knowing it!

What does API Testing mean?

First of all, we mean testing VIA API. "API testing" is a commonly used term, they really say so, but technically the term is incorrect. We do not test the API, we do not test the GUI (graphical interface). We are testing some kind of functionality through a graphical or software interface.



But this is an established expression. You can use it and say “API testing”. And when we talk about it, we mean:

• API level self-tests
• or integration between two different systems.

Integration - when one system communicates with another through some kind of data transfer protocol. This is called the Remote API, that is, communication over the network, over some protocol (HTTP, JMS, etc.). In contrast to it, there is also the Local API (aka “Shared memory API”) - this is the API by which the program communicates with itself or communicates with another program within the same virtual memory.







When we talk about testing APIs, most often we mean testing Remote APIs. When we have two systems located on different computers that somehow communicate with each other.



And if you see “API testing” in the vacancy, most likely this implies the ability to call a SOAP or REST service and test it. Although it is always worth clarifying!

Summary

API (Application programming interface) is a contract that a program provides. "I can be contacted this way and that, I undertake to do this and that."



The contract includes:

• the operation itself that we can perform
• input data
• output data (data content or error message).
".