review

In the last section, we wrote the interface for adding use cases, and adopted jsonschema for parameter verification. Of course, it was not a good way, at least it solved the problem of field verification.

In this section we are going to do two things, one is to complete the page for the new use cases, and the other is to show the use cases we have already added.

Consider adding a use case page

In the last section we provided a page for such a use case tree, notice that there is a + button, but previously it had no effect.

Let me explain why clicking + does not bring up the form for adding use cases directly. That is because we may open up the use case directory later, instead of only having directory/use cases as we do now, so we may add a directory later.

Ok, so what we’re going to write now is the form of the use case. According to my design, it is to fill in some core data, which is the necessary fields of a use case.

Here I pull out the setup+teardown of the use case as a separate module, a basic use case that does not contain setup and teardown. Since we only support HTTP requests for the time being, the core fields are as follows:

  • Use case name

  • Use case directory

  • priority

  • state

  • Request type

  • tag

  • Request way

  • Request the address

    Others are optional and can be added if needed, such as headers, and so on. I think about putting this information into a Drawer component for the user to fill out and submit a form.

Some ideas

Before, THE author was thinking while doing, there may be many things when doing not reasonable, will not be a very perfect version. So the author now changed the playing method, is to finish a part of the first, and then for this part of the content. So here’s the first page I wrote:

The general page is divided into two parts: use case information and request information.

Modify the postman page before

Postman.jsx does not have a wrapped form component. That is, there is no effect like this:

The Form component is an important one of ANTD and is used specifically for Form validation.

But because our previous Postman page needed to be open for user debugging, we needed to write a new component called PostManForm.jsx.

Since we need to get the headers value later, we separate the headers/body method from the setHeaders/setBody method.

In fact, here I would like to add descriptions, because for the react of hooks is not very familiar with the author, there may be state management chaos, but considering before familiar DVA and Reducers related knowledge is relatively obscure, so I won’t informally, after all we are not professional front end, there are some things to solve, We need to optimize. Of course, if the big guy has a better way to deal with, THE author is willing to learn modestly.

Note that I have attached the form. Item component to both the URL and request methods, and this component can make it an Item of the Form, thus giving it the GIF effect above. However, you have to split the two controls, otherwise the display will be problematic.

Headers doesn’t support a form because it’s a list, and body is a third-party component, so we’ll pass on that. The rest of the code is basically similar to postman.jsx.

Write the add use case form

  • rendering

  • Code section

  • onOk

    Submit the method triggered by the form. Add body and headerparameters.

  • translateHeaders

    Because our headers is a list, we’re going to convert it to a string.

Drawer is the Drawer component in the diagram, which is very modal. The footer inside is the “submit” and “cancel” buttons at the bottom, corresponding to the onOk and onCancel methods, respectively.

The Form is then nested with two large modules: use case information and request information.

As you can see, the use case information and the request information are H3 tags and border-left.

The fields. Map in the middle is the custom form component, which is filled out by parsing JSON.

In fact, if people do not understand React, it seems to be a waste of time. Feel not very suitable for entry!! Epsilon = (´ &western ` *))) well

Anyway, this is the GIF effect, and then the presentation page. If you are interested, you can take more time to familiarize yourself with React and Ant Design. Although testing is an internal tool, when it comes to teamwork, many people use similar technology stacks to complete different functional modules. I personally think testing should learn some VUE/React, otherwise it is purely back-end. The front end is really hard to find the right partner to do it for you.

There are also changes to the back end

  • New models/TestCase. Py
from app.models import db
from datetime import datetime


class TestCase(db.Model) :
    id = db.Column(db.INT, primary_key=True)
    name = db.Column(db.String(32), unique=True, index=True)
    request_type = db.Column(db.INT, default=1, comment=Request type 1: HTTP 2: GRPC 3: Dubbo)
    url = db.Column(db.TEXT, nullable=False, comment="The request url")
    request_method = db.Column(db.String(12), nullable=True, comment="Request mode, null if non-HTTP")
    request_header = db.Column(db.TEXT, comment="Request header, nullable")
    # params = db.column (db.text, comment=" ") # params = db.column (db.text, comment=" ")
    body = db.Column(db.TEXT, comment="Request body")
    project_id = db.Column(db.INT, comment="Project")
    tag = db.Column(db.String(64), comment="Use Case label")
    status = db.Column(db.INT, comment="Use-case status: 1: Commissioning 2: temporarily closed 3: Normal operation")
    priority = db.Column(db.String(3), comment="Use case priority: P0-P3")
    catalogue = db.Column(db.String(12), comment="Use Case Directory")
    # expected = db.Column(db.TEXT, comment=" expected result, support el expression ", nullable=False)
    created_at = db.Column(db.DATETIME, nullable=False)
    updated_at = db.Column(db.DATETIME, nullable=False)
    deleted_at = db.Column(db.DATETIME)
    create_user = db.Column(db.INT, nullable=False)
    update_user = db.Column(db.INT, nullable=False)

    def __init__(self, name, request_type, url, project_id, status, priority, create_user,
                 catalogue, tag=None, request_header=None, body=None, request_method=None) :
        self.name = name
        self.request_type = request_type
        self.url = url
        self.priority = priority
        self.project_id = project_id
        self.tag = tag
        self.catalogue = catalogue
        self.status = status
        # self.expected = expected
        self.body = body
        self.create_user = create_user
        self.update_user = create_user
        self.request_header = request_header
        self.request_method = request_method
        self.created_at = datetime.now()
        self.updated_at = datetime.now()

Copy the code

The expected and params fields have been removed, because params will be brought into the URL now, so this field is not needed.

Today’s content, also can only here, long-winded for a long time. The use case details page is shown in the next section.