This is the first day of my participation in the August Text Challenge.More challenges in August
Hi, I’m Milo, a test development blogger!
Welcome everyone to pay attention to my public number: test development pit goods.
review
We wrote a method for adding data constructors in the previous article, so let’s move on to use cases.
Write a method to query all constructors against case_id
Write a method to find the data constructor
- ConstructorDao adds a static method
For no other reason, because if we judge the case has data structure data, then we will get this data!
Transform Executor class
- New method for parsing parameters
Remember what we said before about global variable substitution? It was only replacing headers, body, etc., but it wasn’t very comprehensive.
A TestCase class with too many fields. After we fetch the data, we need to check each field, so here we go through all the fields in a TestCase, to mine the variables, which will be the most comprehensive. (It’s also inefficient, but since our data constructor only tells us to return, not where to use it, this process is necessary.)
In this case, request_header is already treated as a JSON string, so the data in it is naturally a string and we don’t need to serialize it once.
- Although the decorator generates a lot of logs automatically, it’s not enough
- New get construct data and execute construct data methods
As you can see, the constructor currently only supports type == 0, which is the test case type. If it is a case, the Executor will generate one again, execute the use case within the use case, and finally get the result information and stuff all the case execution data into the params dictionary that we passed in, based on the value we set.
This process records all the data in the construction conditions, and makes a good foundation for future data retrieval.
Modify the RUN method
Three new parameters are added: params_pool, request_param, and path.
Explain:
-
params_pool
This is the overall global datapool, accumulated from the first use case, so we have a convention not to fill in duplicate return values.
If constructor 1 returns value1 and constructor 2 returns value2, the final value of the params_pool would be:
{
"value1": value1 Returns data."value2": value2 returns data}Copy the code-
request_param
One thing I missed in the last article is that we have a field for dynamic parameters. Since our use-case parameters would be hard to use if written dead, we want to make the use-case live, not dead data, but not so rigid as global variables.
So we need to make the use case accept the corresponding data to execute, for example, a login use case, in which the user name is ABC, here I pass in the user woody that my scenario needs to achieve the purpose of modifying the use case through parameters.
-
path
This is easy to understand, my case path. For example, if I’m A use case and I’m executing A construction condition 1->B, I’ll give A path so I don’t get messy:
A->B, so it’s easier to tell the difference.
Going into the details of the use case, let’s break down the use case process step by step so that the thinking is clear.
Back to the original example
We still need to log in and request the user list interface through the JSESSIONID.
What should we do?
- Write a login use case
Test it out:
-
Add the login use case as a data constructor to query all user lists
-
Take the data
When we log in, we need to use the JSESSIONID in the cookie.
Note here that we set the variable after login to blog_login, get the corresponding data via cookies.JSESSIONID, and pass it to the current use case.
Look at the results:
Since the log was not very friendly, it had to be modified later. Assertions have not been added, so work on that!
If you modify or miswrite this variable:
The official documentation
The online demo is at http://47.112.32.195/
Front-end repository: github.com/wuranxu/pit…
Backend repository: github.com/wuranxu/pit…
The official documentation