COVID-19 is rampant. Based on its long-term experience in remote R & D collaboration, eolink has launched a remote collaboration guide for API management for enterprises. The following solutions have been verified not only in eolink, but also in many customers. We hope to help you quickly understand how to apply API management and automated testing to practical remote office.
01. Development process, pain points and solutions of API management
In the past, many R & D teams did not pay attention to API management in the R & D process. They thought that API management was nothing more than managing API documents. They just needed to write API descriptions in word documents or wikis, and then send API documents to front-end and testers in the form of files or wikis when teamwork was needed. At this time, API management is extensive. We call it the 1.0 era.
However, with the increasing popularity of agile concept, people began to find that the traditional API management only focuses on the management of API documents is not enough. There are the following obvious problems:
API documentation is not standardized:Lack of unified document format, short, omitted or no detailed description (developers always feel they can understand).
Inconsistent storage platform:Each project team within the company has its own usage habits, and even multiple API management tools can exist in a project at the same time. The inconsistent platform makes it impossible to maintain and cooperate efficiently.
The document is not updated in time:The development team is used to developing documents first and then supplement them. They think that the documents are only an additional content for the development work, resulting in untimely updates.
Change history:Due to the failure to maintain the documents in time, when it is necessary to go back to check the project or carry out work handover, it will be found that looking at the documents is better than looking at the code, which will slow down the work progress.
No communication cost reduction:For the above reasons, front-end, back-end, testing, operation and maintenance and other members often cause disputes due to unclear documents, sometimes increasing the communication cost.
In order to solve the above problems, the tools in the 2.0 era began to think about how to combine development and testing, such as generating API documents through code annotations to reduce the burden of writing documents for back-end development, and testing directly based on API documents. The most prominent products in this era are swagger, postman, JMeter, soupui and other products.
With the promotion of the concept of integration of R & D and testing, these products have gradually become the mainstream API management and testing tools, with a huge user group.
However, remote collaboration was not popular when the above products appeared, so their product design is basically based on local development and personal use. Therefore, when encountering higher and higher iteration speed and quality requirements, they are unable to meet the following problems:
Front end development progress is subject to the back end:Simple API documents lack mock API. The front end needs to wait for the back-end development to get the test data. It is time-consuming and laborious to construct the test data by itself.
Document change without notification:The back-end development changes the code and interface, and is used to oral communication instead of clearly pointing out the modified content through documents, resulting in high communication cost in the later stage.
Inconvenient and repetitive interface test:You need to look at the interface document and then use another tool for testing. If the interface changes, the written test will be invalidated and the repeated workload will be increased.
Work results cannot be shared:Each tester writes test scripts with stand-alone test tools, but they can’t share and cooperate.
Test work is not automated:I always hope to promote automated testing, but it doesn’t really work. Every day “bit by bit” still consumes a lot of energy of the testing team.
The test effect cannot be quantified:Unable to accurately understand the test effect, no one can say how the test is today, yesterday, last week and this month, and how it has improved compared with before.
Passive test work:The test is always carried out last, unable to participate in the project discussion, fast and large-scale regression test, and even unable to complete the test task on time, resulting in the delay of the project or going online with anxiety.
Moreover, these products do not solve the core problem in the process of API R & D Cooperation: how toDevelopment, testing, operation and maintenance, teamworkCombine the four to become a flexible and unified API management platform suitable for the team. And can provide direct support for subsequent API monitoring, operation and maintenance.
We take the tools that realize the four elements of development, testing, operation and maintenance and cooperation as the symbol of products in the 3.0 era. Since its establishment in 2017, eolinker has been committed to building API life cycle management solutions. At present, it is the largest online API R & D management platform in China. Its online SaaS products and offline privatization products include:
API generation platform (API factory)
API R & D management and automated test platform (API studio)
API monitoring platform
API microservice gateway platform (API gateway)
API open platform, to be released soon
02. Theoretical basis of eolink API Studio: document and test driven
I believe you have heard of the following development models:Document driven development (DDD)as well asTest Driven Development (TDD)。
Document driven development refers to writing the document before development, clarifying the functional requirements, input and output parameter definitions, exception handling, etc. This is like we need to understand the requirements of the topic before doing the topic, otherwise it is easy to rework if we write without examining the topic.
Test driven development refers to writing the test scheme / use cases before development, and only developing the functions that can successfully pass the test. If the test fails, it will continue to improve. This is just like that we will understand the standards of passing the exam before the exam. If we answer without standards, there will be no good results.
The combination of the above two development methods is the design concept of eolinker API Studio: document and Test Driven Development (dtdd). Simply put:
1. Replace oral agreements and notes with standard documents,Let the development, testing, operation and maintenance and cooperation have traces to follow;
2. Quickly use the test results to promote the progress,Let the team communicate more fully and have a basis for management, so as to realize agile development;
Therefore, in eolinker API studio,Almost all collaboration work is carried out around API documents, after you create the API document, you can view the changes of the API at any time, initiate API tests according to the API document, write API test cases, create mock API, and conduct API automation tests.
Therefore, we highly recommend that you try this way to work.
03. Get to know API studio
Create the first API management project
In eolinker API studio, all APIs are properly managed in the form of projects, so we first need to create an API management project. At the same time, we also provide one click import function, which can quickly migrate the data in swagger, postman, rap, Yapi and other products to eolinker.
Create API document
In API studio, you can create API documents in three ways:
To manually create an API document:Apistudio provides a very comprehensive API document format, which can record your API information in detail. This method is suitable for all users and is also the way we recommend.
Associate the project with swagger URL, and API studio automatically obtains the latest API documents from this address:This approach is suitable for users who are already using swagger and tend to write documents in code comments. However, this method will bring the problem of code intrusion, which adds a lot of irrelevant information to the code, thus increasing the maintenance cost.
Associated project and code warehouse:API studio automatically scans code annotations from the code warehouse to generate API documents. At present, this method supports Java and PHP. This way will also bring the problem of code intrusion.
After we have created API documents, we can see clear API document information in API studio, and on this basis, we can test API, write API test cases, write mock API, manage API version and so on.
One click API test
After we create the API document, we can test the API immediately. API Studio provides the following main features to help testers quickly initiate API testing:
1. Support local test, LAN test, online test, etc;
2. Support one click switching test environment, use global variables, add additional request parameters, change request address, etc;
3. Support direct interface editing of JSON and XML request data without handwritten JSON, XML and other data structures;
4. Support to save test data as test cases, which can be directly used for testing in the future;
5. Support batch testing API, such as testing various situations of login interface and returning real-time test data;
6. Support writing code for signature, encryption and decryption, generating random data and other operations during the test process;
The following figure: JSON data can be written directly in the test interface.
Figure below: switch the test environment and initiate the test in one second.
Batch test multiple API use cases to liberate the testing labor force
In the past cooperation methods, testers always work last, unable to participate in project discussion, rapid and large-scale regression test, and even unable to complete the test task on time, resulting in project delay or online with anxiety.
In API Studio:
1. Since the collaboration is based on API documents, testers can intervene immediately after the back-end developers write the API documents,Write test cases based on API documentsMove the test forward;
2. When API development is complete,Testers can test all test cases of API with one clickAnd get a detailed test report. Back end developers only need to see the test results to know whether their APIs meet the test requirements. If there are exceptions, they can make targeted improvements;
3. After the API changes, the tester only needs toOne click API regression test, truly liberate the labor force;
Through the above methods, the back-end and testers can communicate more closely to complete test driven development.
The following figure: batch test various data conditions of API and obtain detailed test report. You can view the causes of API exceptions in the report.
Build mock API to free the front end from the back end
The development progress of the front-end and back-end API development needs to be connected with each other in the waterfall mode. Therefore, the development progress of the front-end and back-end API development needs to be completed first.
Through the mock API, you canWrite the data generation rules of API in advance, API studio dynamically generates the return data of API. Developers access the mock API to obtain the data required by the page and complete the docking work.
The mock API supports the return of different HTTP status code, header, body and other data according to different request parameters。 You can create multiple mock APIs in one API document to simulate various requests initiated by the front-end to facilitate the verification of the front-end logic.
When the project is officially released, just replace the address prefix of mock API with the actual access address.
For example, the address prefix of the mock API in the same project is the same (such as mock.eolinker. COM / uasyd1 /…), so the address prefix of the mock API can be used as a global variable in the code. When the project goes online, you only need to replace the value of the variable to change the API request address prefix of the whole project.
The following figure: the API creates multiple mock APIs. The front end can pass different request parameters to obtain the corresponding return results. For example, when the user name is Jack Liu, it returns login success, and when the user name is Percy, it returns login failure or random string.
Automatically notify relevant members when API documents change
When maintaining the API, many users often encounter the problem that the API document has changed, but the front-end and testers do not know. In order to solve this pain point, API Studio provides the function of change notification. When the API changes, it will automatically notify relevant members through e-mail and on-site letter, and display the changed content.
In API studio, we divide the status of API into the following stages, so that members can understand the current status of API when viewing API documents.
Comment and mark API documents directly during remote collaboration
When you conduct remote collaboration, you can directly post comments on the API document. All communication contents will be retained with the API document and classified according to the version, rather than scattered in various chat tools. In this way, we can avoid wasting time when we can’t find a basis for later communication.
Below: commented directly in the API document and @ viewed by another member of the project.
View, rollback and compare API editing history
API studio also provides a very powerful API version management function. You can roll back to any API document version at any time, and you can also compare the differences between the two versions.
When you can’t communicate what’s updated in language, you might as well try version comparison~
As follows: compared with the historical version, the current version has deleted some parameters, which will be marked in red in the interface.
In addition, there is
API studio has more functions than that. You can carry out strict personnel permission management, API status code management, project document management, test environment management, etc. in the project, all in order to make team cooperation easier and more efficient
04. Advanced! Build API automated test platform through API studio
Quickly understand the leading API automated testing in the market
API studio also provides the leading API automatic test function in the market:
Zero code automated testing:API automatic testing can be carried out without writing any code;
Support operation database:During the test process, it supports the operation of the database and the implementation of data insertion, deletion, editing and other operations;
Data driven test:A test case supports testing multiple groups of data and generating test reports respectively;
Automatically generate test reports:Each test can generate a detailed test report, which supports online viewing and offline downloading;
Support scheduled test tasks:Set the timer to automatically execute the test task and send the report to the designated person’s mailbox;
Support open API trigger test:Jenkins can be connected through API to conduct API automatic test at any time;
Very low learning threshold:After 15 minutes of training, you can quickly start API automatic test;
Can help you quickly solve the following common problems:
Before the release of requirements, the project needs to be regression tested. The traditional testing method has narrow coverage and low efficiency.Automatic testing can be used to improve the scope and efficiency of testing;
After the change of product demand / code, the tester cannot determine the test scope.Automated testing can be used for large-scale regression testingEnsure the normal operation of basic business;
The traditional test method has a long cycle, and can not perform the test every day, every hour and 24 hours at any time. It also depends on people’s professionalism, and the test effect is unreliable. Automated testing with APIRegularly test the task or integrate API studio into Jenkins to trigger the test upon code submission and get the test report in real time.
The traditional test team members lack cooperation and do not know each other’s test cases, test scripts and test results, resulting in repeated work. Using API studioRealize the online cooperation of the test team.
After the test team uses API studio to maintain API automated test cases, it can effectively solve the above problems and help the test teamImprove testing ability and efficiency.
API Studio provides two test case writing modes: UI and code mode:
UI mode:It supports editing API automation test cases through interface mode, and can complete more complex API automation testing without writing code.
Due to space reasons, we only demonstrate the automatic test effect of API studio here. For details, please visit the official website of eolinker.
As shown in the figure below, you can edit the API test process, data management between APIs, returned verification rules, or even insert database operations through the interface, and thenOne click to get the test report.
In script mode, write a few lines of code to initiate the test, andSupport automatic generation of test scripts from API documents!
We can select multiple test cases,One click batch test and get the test report.
More ways to trigger API automated testing
API Studio provides a variety of automatic test triggering methods:
1. Triggered by open API, it can be connected to Jenkins and other continuous development platforms;
2. Timing trigger;
3. Manual trigger;
Flexible use can create a test efficiency artifact that belongs to you!
05. More API solutions for eolink
The rampant epidemic has hindered the operation of countless enterprises. The above is the API management remote cooperation guide launched by eolink for enterprises in combination with its long-term experience in remote R & D cooperation. The following scheme has been verified not only within eolink, but also among many customers. I hope it can help you quickly understand how to apply API management and automated testing to practical remote office.
We hope to use this set of theories and products to help more enterprises free themselves from the traditional and inefficient development methods. We also wish that the majority of developers and enterprises carrying the Chinese dream can work together to tide over this difficulty, and eolink will always be with you!
The interface management tool used in the figure is eolink. If you are interested, you can use it yourself:www.eolink.com