This is the 19th day of my participation in the August More Text Challenge.
Hello, everyone ~ I’m Milo, welcome to pay attention to my public account test development pit goods!
This is an interface testing platform under development, so far 15% of the functions have been completed, get on the bus and learn together!
review
In the last post, we went on an errand to get the editor piece. The reason I care so much about the editor experience is that later on we need users to supplement our pages with Python or other scripts, and without a decent editor, it’s useless.
However, we found that the editor would skip and found the specific reason: we added the code completion prompt every time in the render process, which was not reasonable, so we need to change the editor.
Think about your current deficiencies
In fact, the current situation is complicated, when we write use cases, we have to enter the project, and then find the use case list TAB page in the project.
Do you think this is not good ~
It would be much better if we had a directory on the left and a list of cases on the right. And with the development of business, directory classification can not be as at present only 2 levels.
Anyway, let’s try it out
Design use case table of contents
After removing basic information such as primary keys, update/create time and user, there are only three core fields:
-
project_id
Our catalog needs to be linked to the project, so that catalog can be well classified, so as to achieve the purpose of case classification.
-
name
Directory name, this need not say more.
-
parent
This is a key field because our directory supports nesting, and if a directory has no parent, it is a root directory.
We're going to show a tree structure, and we can't do without this thing
Write add, delete and change interface
- insert
Some people may be very confused, why set a unique index, but also to query the database first? In fact, the unique index is our bottom-of-the-pocket solution, is to control the uniqueness of data. But we should avoid the possibility of repeated data from the perspective of business, so there is such a judgment, this is just my personal understanding.
Begin with session.add automatically submits the data to the database after session.add.
Test it on Postman:
- Update and delete
It’s basically the same old story, which is why people say CRUD BOY is boring, because it does seem to have average technical content.
Next, improve the interface for modifying and deleting:
highlight
The next step is to write the interface to get the directory tree
Get all directories by project_id
We need to pull out all the directories under a project at once.
Write the get_testcase_directory_tree method
Here’s a little bit more complicated, so let’s break it down one by one:
- Get all directory trees by project ID
- Create the final result: ANS
- Create a directory ID -> directory mapping
- Create a map for the parent -> subdirectory, which is a list
- If parent is empty, it is the root directory and we add it to ans. If parent is not the root directory, we take its parent and write it to parent_map
- Finally, set the id -> directory mapping
If we get all the root directories in one pass, and which children the root directory has, the directory ID -> three important clues to the directory.
- Go through ans and stuff their children and grandchildren into the children list
Get_directory (parent_map) : get_directory (parent_map) : get_directory (parent_map) : get_directory (parent_map)
If so, iterate over current, which is the list of subdirectories, then get the information for the subdirectories from ANS_map, create a new child list, add the information for the current subdirectory to the children under the parent directory, and recursively continue to find the subdirectories of the subdirectory.
This is repeated to create a tree. Write the interface to get the directory tree:
Let’s look at the end result
Today’s content to share here, interested friends can begin to write together! ~
Experience online: pity. Buzz