Apifox, like Postman, has the most basic function for interface tuning.
A slightly more advanced usage can use Apifox to generate codes for sending requests in various languages, make requests for Image/File, and perform data verification and testing for Request Body and Response Body.
Just doing this satisfies a developer’s usage scenario. The more advanced use of Apifox can benefit the entire team, meeting all stages of development and testing, covering the development environment, test environment, and production environment. Further automation of development, testing, and documentation
Apifox API management layer
Apifox organizes all requests on the back end by function or business module, using Markdown to add appropriate descriptions of all requests and examples.
Let’s take a look at Apifox’s advice on organizing requests and grouping.
- Project: Corresponds to a service within a team. Projects are shared among all members of the project team (server, Client, QA). You can add requests, documentation, single API tests, and so on to the entire project. Most importantly, you can add test flows and data models, as discussed later. Projects not initially requested by ApifOX can be automatically converted to projects organized by ApifOX according to apidOC, Swagger, etc.
- Grouping: corresponds to a module or hierarchy of subroutes. Such as
router.use('/users')
All the requests are in onegroupingCan be nested with each other based on routesgrouping. - Request: Corresponds to one API request, one document.
- Example: Different parameters and responses to a request, for Mock Servers and documents.
PS: Mock Server and team sharing apis exist in Postman as well, but apifox is all free, so I have the advantage.
PS2: A small suggestion, if you can run through the project through a Proxy, collect all the requests and store them as Apifox project, you can save the tedious of adding API manually to the maximum. Especially if it’s just been converted to Apifox by some other tool.
The document
Apifox automatically generates documentation to facilitate team collaboration, addressing major bugs such as manual documentation and late updates.
Hey, back end, that’s you. I wasted three days and nights trying to keep my files up to date.
However, there are too many redundant fields, so a better solution would be to perform JSON validation of the request in the test, while also acting as part of the document. After all, JSON-schema is designed to describe data and make it more readable.
Speaking of requests above, the documentation for the response can be jSON-schema validation or descriptions of each field, with more test cases representing more detail.
Mock
When the server side has not written the API, the client can customize the rules to generate the interface.
See more “How Does a front-end gracefully Mock Data 🏃” Tips every front-end should learn
test
For every Request, there needs to be a test case to verify that the response is successful, the response time is too long, or the data type of the response JSON is correct.
BDD tests can be performed using Pm. Expect, which is similar to CHAI and easy to get started with if you are familiar with chai, while pm. Expect uses the underlying IMPLEMENTATION of CHAI, consistent with the CHAI BDD API.
Apifox also has SOME HTTP-related testing apis, such as Status Code, Header, and Body, and also provides snippets.
// The response succeeded
pm.test('Status code is 200'.() = > {
pm.response.to.have.status(200)})// Respond successfully chai. Expect
pm.test('Status code is 200'.() = > {
chai.expect(pm.response).to.have.property('code'.200)})// Verify the response data
pm.test('Page is 100'.() = > {
const jsonData = pm.response.json()
chai.expect(jsonData.page).to.eql(100)})Copy the code
That’s not the point. With Apifox, you can interact with a graphical interface without writing code to test the interface.
The above screenshots verify the following data
- The API request succeeded. The status code must be 200
- The response body data must be JSON
- The code field in the response body must be a number
Example: Test request parameters
A request takes several parameters, such as queryString (search) for GET and body for POST, and each parameter has a different data structure in response.
If a request returns a completely different JSON schema for different parameters, you can write two apis to test separately.
If the same Json Schema is returned with different values, two different examples are used for testing.
Integration testing
Once a single API test passes, all requests need to be integrated for testing. Two problems arise
- How do I ensure API dependencies
- How is data passed between apis
Environment variables can be used to maintain data in ApifOX, replaced by {{}} placeholders in requests.
A common scenario is that a project uses a token to store login information, and each request needs to carry the token. The token’s environment variables can be set in the login test code
const url = 'http://{{HOST}}/api/login'
pm.test('There is a token'.() = > {
const jsonData = pm.response.json()
pm.expect(jsonData.token).to.a('string')
pm.environment.set('token', jsonData.token)
})
const urlNext = 'http://{{HOST}}/api/profile? token={{token}}'
Copy the code
PS: So how do you automatically control the order of all the tests? For example, if the login succeeds, go to step 2. If the login fails, go to Step 3
- The login
- Posting
- XXX
Continuous integration
How to integrate integration tests with projects, incorporate them into version management, keep test records, and locate bugs on time.
You can use the Apifox CLI, but only to test offline data. Refer to the documentation Apifox: Continuous Integration
$ apifox run examples/sample.apifox-cli.json -r cli,html
Copy the code
Summary and more questions summary
-
How do I write test cases
- Apifox underlying use
[chai.js](http://chaijs.com/api/bdd/)
BDD syntax as an assertion library, plus some special syntax. - Apifox can verify data interactively through a graphical interface
- Apifox underlying use
-
How to debug
Click the menu bar View -> Show Devtools (Show Postman Console) to View the response and check the output.
-
How do integration tests manage request dependencies
For example, the two apis need to have a dependency relationship, such as when a user is created (registered), to obtain his personal information. To obtain personal information, you need to rely on the create user API.
You can manage dependencies using Environment Variables
-
How does it integrate into a server-side project
You can use the NPM package Apifox – CLI to integrate into your project