This is the first day of my participation in the First Challenge 2022.

Hello ~ I’m Milo! I am building an open source interface testing platform from 0 to 1, and also writing a set of corresponding tutorials, I hope you can support more. Welcome to follow my public account Milo test diary, get the latest article tutorial!

review

In the last section, we wrote the client of OSS. But we do have a purpose. We know that we sometimes test some interface, for example, bulk import, in which case we send a file (Excel or CSV) to the interface.

So how do we store our test data? It’s up to OSS to do its job. In the past, we used to put a directory to hold the test data. Now we just put the data in OSS.

Today we will implement HTTP requests to support OSS file uploads. We need to fix a few bugs before we do that (there are many, but just one example)

It’s been a long time.It isn't reallyWaiting for the nuggets to move. hiahia

Bug warning

  • An error is reported when no data is asserted

Two return values are required, but we only give one when there is no assertion, true sloppy.

rendering

Train of thought

In the HTTP request containing the body, we forced the HTTP request to choose either of the two:

  • Either json

  • Or form form

    For this file format, there is no choice, so we have to store a field:

    Body_type, this field tells us what type body is, which corresponds to this data:

0 for None, 2 for form-data, 1 for RAW (JSON), 3 for X-www-form-urlencoded, and the rest in sequence.

So we’re going to go to the use case and add body_type, which defaults to 1 (because our interface type is mostly JSON).

Then we can return different bodies according to different data types in the HTTP request.

New field body_type

Modify app/models/test_case.py to add body_type field.

Adjust the pydantic

Before, our schema data was stored under the router, but later we had some problems with loop introduction. So I put all this data under the Models, just to be clear.

Add the configuration

We used to love writing 1,2,3,4:

if case_type == 1:
Copy the code

This kind of code, but actually this kind of stuff can be put in config, so if we want to change the rules, it’s very convenient, and it’s hard to remember what type it is if you look at 1,2,3,4.

This time, I must change.

Add a new subclass class Config: class BodyType:

Modify the Http request client

Since whether we send json or form, the general change is this method:

Like this, now that we have a new parameter, I’m going to encapsulate a new method, because this HTTP online request needs to be used, and case execution needs to be used as well.

Without further ado, let’s go straight to the code:

For a regular form, data receives a dict, for a json, and for a file, for a FormData:

Since we store the body with oss file information, we need to parse the data first, that is, deserialize it and then fetch the corresponding file or text to form FormData.

  • Run case-related changes

We used to add headers for JSON requests, but now we put them in the HTTP client, so we can simplify things a little bit.

  • Replace_body changes

This needs to be changed slightly to replace the body data only if it is json, as this substitution currently only supports dictionary types.

The front part

Front-end part OF my writing is too bad, interested to see the source code (I can’t read), living shit mountain, really.

However, I have solved the problem in various ways, and I plan to leave the HTTP part at that.

I added an editable table component that is different because it needs to determine the VALUE cell input control based on whether FILE or TEXT is selected:

When you switch to TEXT, the selection box on the right becomes the input box.

As you can see, we called our own HTTP file upload method (upload) and completed the test function of the file upload.