Hello ~ I’m Milo! This is a complete series of interface test platform tutorials, hoping to learn with you, from 0 to 1 to build an open source platform. Welcome to pay attention to my public number test development pit goods, get the latest article tutorial!
review
In the previous section we inserted a digression: deployment-related, but let’s continue to return to case-related topics in this section.
A new chapter
In fact, after the previous use case writing related page was abandoned, I have been thinking about how to build a reasonable, user-friendly use case writing page.
But I didn’t find a good solution, and I looked at some other good open source projects. Eventually, I went back to Tab mode:
The end result might look something like this:
It is mainly divided into two parts, above is the data related to use cases, below is the core of writing use cases, divided into common modules.
There are four steps below, data constructor (preconditions) -> interface request -> Assertion -> data cleanup.
Ergonomic design setUp -> test -> Assert -> tearDown
Relevant modification
These are basically front-end page changes, but there will be some back-end interface changes as well. So we have to adapt some of the interfaces.
Write methods to get preconditions based on the use case ID
Note that there is a hint here: our preconditions must be executed in a certain order, but my side of sorting by creation time is obviously unfriendly, but we will support the ability to change the order of the preconditions later.
Adjust the method of getting the list of use cases
Change to asynchronous execution, and support to obtain cases by directory, reduce the number of large-scale case query.
Adjust the method of getting a single case
We used to just take TestCase, now we need to take the basic information of the case, the preconditions, the assertions, and then encapsulate it in a dictionary and return it, and then we have postconditions.
Join is not chosen here, because there are many tables involved, so we have inquired for many times. Subsequently, we can put all the queried data into Redis to reduce the pressure on the database.
The reason why we spend so much time on this transformation is because it was really difficult to use before.
For example, I find it hard to add a precondition and not be able to show it.
That’s it for today, and the next section is on controlling the order in which preconditions are executed.