Some people may say, write interface automation CASE how simple, write a parameter to send the request finished, but also pay attention to what?

Yes, compared to UI automation cases where you have to write various locators, interface automation cases are actually much easier to write. This is also an advantage of interface automation, faster development efficiency.

But writing fast is not the same as writing well, and this chapter will talk about interface automation cases.

First, the case should be easy to read and maintain

Since you are writing an automated case, you are also writing code, so the readability of code cannot be ignored. In addition to the Python code specification, pay attention to the case structure, which makes it easy to see at a glance.

In fact, it is similar to using the Postman test interface by hand, just write down everything clearly. The test interface usually has three steps:

  1. Incoming request parameters
  2. Send the request to the interface
  3. Check whether the result returned by the interface meets the expectation

In this way, we also take three steps in automating the case of the interface.

def test_query_activity_manual(init_activitiy_manual, del_activity): Get (activity_url, params= requests. Get (activity_url, params= requests. headers=HEADER) result = r.json() assert result["status"] == 0 assert result["data"]["content"][-1]["id"] == 10087 assert result["data"]["content"][-1]["winWay"] == 0Copy the code

Is it clearer to write it this way? Anyone can read your code and feel comfortable debugging it yourself.

Ii. Stability of case

1. Why do people often make mistakes when writing cases

The stability of an automated case is more important than the ease of reading and maintenance mentioned above. If you write test cases that run error-prone, there’s no point in interface automation, and the people who use it will lose trust in your framework.

I believe that when you finish writing a case, you must be debugging through, so why can this case run at that time, a few days can not run? In my observation, a lot of time is caused by “test data”. Automatic case depends on the test data is not stable, maybe your test data was accidentally deleted by others, or the test data generated by your other case affects the test data of your case, etc., are more common reasons.

I’ve found in my work that some people like to call interfaces to generate the test data they want, that is, rely on another interface to generate the test data. An attractive advantage of this approach is that you don’t need to know much about the upstream and downstream data relationships of the interfaces under test. After the interfaces are called, the system logic will generate the corresponding data. Yes, it’s tempting, but your case is bound to suffer when the interface that generated the data dies or returns the wrong data.

In addition, some people like to use the data generated by the last case for the next case, the same reason, if the last interface error, the next will also be affected, but you can say that the affected case failed because the interface itself has a bug? Obviously not.

2, remove the root, SQL generated test data

To put it bluntly, the above two cases are due to the unstable way in which test data is generated, which can lead to friendly fire. So how did I deal with it? The idea is very simple, I directly use SQL in the test environment to generate the test data I want, use it and then delete it. At work, I do this, the results are very stable.

In addition, a recent reading of the Fixture module in pyTest’s official documentation showed how powerful and well-designed fixtures are. It was also emphasized that the environment in which the test case was tested should be kept clean.

Therefore, my case writing principle is: any case can be run at any time, not affected by other cases.

I usually put individual interface cases in a module. For example, if there are six interfaces, I will write six modules, each module has tests for all scenarios of the interface, such as parameter verification, scenarios where different parameters result in different results (data-driven), etc.

For the business flow test of the six interfaces, I will put it in a separate module. In this module, I will only test the business flow and prove that their business logic is no problem. I will not pay attention to the test of other scenarios of a single interface. In business flow testing, test data is passed between cases for use.

3. Advantages and disadvantages of the above two ways

Let’s call the above two methods method 1 and method 2 in order, of which method 2 is my preferred method.

First, the advantages and disadvantages of mode 1:

  • Advantages: Testers do not need to worry about the database layer related logic, simple and easy.
  • Disadvantages: Too dependent on other interface to create data, as long as there is a problem with the dependency interface, case will be affected.

Let’s talk about mode 2:

  • Advantages: Not affected by other interfaces, test data can be directly inserted into the database and deleted immediately after use, ensuring a clean test environment and preventing test data from affecting other cases.
  • Disadvantages: Testers need to be aware of the table relationships involved behind the business logic, as many interfaces involve more than one table, which can be cumbersome.

In fact, compared with method 1, I think method 2 can not be regarded as a strict disadvantage, although you understand the relationship between tables and write SQL is a bit troublesome, but also deepen your understanding of the business, the most important is the case stability, such interface automation is meaningful.

Third, a bit of personal practice to share

Perhaps some people will agree with my way, but worry about their own SQL write bad, in case of error how to do?

There’s no good way to do that, except to make sure everything is correct. Here are two tips to help you write SQL well.

  1. It is best to know the logical relationship of the table. If you are not clear, please consult the corresponding developer and record it.
  2. Manually create data from a page or interface, then track the data in the database, use the database tools, copy the SQL statement, and then make specific changes.