Hi, I’m Milo, a test development blogger, the world is big, you should check it out!
Welcome everyone to pay attention to my public number: test development pit goods.
This post requires some patience, and if you don’t like it, you can remind the blogger with a like.
review
In the previous article, I found a testable project, but encountered problems requiring login. Normally, it would be convenient to write code that would log in to a method like setUp, store the corresponding JSESSIONID, and then test functions would have unimpeded access to the item using the JSESSIONID.
Looking for a case
Let’s look at a simple example:
As shown in the figure, I want to test an interface that gets a list of users for this page. Because we haven’t sorted out the corresponding interface document, we can only understand this request by looking at the code or capturing packets.
Fortunately, this request is simple, is a GET, and accepts a nickname field. Based on experience, this interface can query user information based on the corresponding user name.
Platform thinking
So what should we do with platforming? We just went through the process.
- Design the use case
- Invoke the login interface to get credentials (token/cookie, etc.)
- Request based on credentials
Interface for getting a user list - Make different nickname based on corresponding use case
- Write the corresponding assertion information based on the use case
If you are familiar with Python+ Excel, you may have added a lot of test data and expected results in Excel. In fact, platformization is similar.
We only need to care about the actual execution of one use case:
- Log in to obtain credentials
- Request the interface by credential
With that in mind, let’s start modifying our Executor class. So what we need to do is execute the login case first, and then execute the test case. In other words, the login use case is the precondition of the test case (setUp/ initialize data operation), and I have given it a name here: the data constructor, because we often talk about interface dependencies, often caused by data, and if we can get credentials after login, then our dependency on login is resolved.
When we execute the use case, the order is, if the use case has a data constructor, then we execute the data constructor method first, in order to get the dependent data.
The Constructor table
The id,deleted_at, CREated_at,create_user,update_user fields are all old stories, so I won’t go over them.
-
type
Our data may come from an HTTP request, a Redis operation, an SQL query, other test cases, and so on. I’ve tentatively settled on three of the most common:
0: testcase 1: sql 2: redis
Others will be added later, such as py script and so on.
-
Name: description of the constructor
-
Enable: Whether to enable the function
For example, one day you don’t need to do this operation temporarily, you can temporarily close, later can open.
-
If you don’t make it public, you can’t make it public
-
Case_id: the case_id of the constructor
-
Value: the return value of the constructor
So if you understand that, I constructed the data so that I could pull it out again. For example, if I set woody=” handsome “and I want to use this handsome guy later on, then the woody will be” value “or” return_value “.
-
Constructor_json: constructing json
Because we have different data, corresponding to different data formats. For example, if I’m a SQL type, I might need some key information like jdbcUrl (address of the database connection), SQL, etc. In this case we’re more comfortable using Mongo as the database. Just to reduce the complexity of the system, and to introduce as few new components as possible, can tolerate.
Define the builder request parameters
Write new data constructor functions
Page operation
- Add constructors for the corresponding use cases
- Select the test case type
The net effect is that the query all users list use case has a data constructor with the user logged in properly.
That’s it for this issue. I’m getting indigestion from so much.
treasure
Online demo address: http://47.112.32.195/
Front-end code repository: github.com/wuranxu/pit…
Back-end code repository: github.com/wuranxu/pit…