Make writing a habit together! This is the 9th day of my participation in the “Gold Digging Day New Plan · April More text Challenge”. Click here for more details.

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 pay attention to my public account Milo test open diary, exchange learning together!

review

In the last section, we optimized the return values. Today, we will follow the lead and try to find our own problems as a product manager.

In fact, most of the time, it is a mystery, so if you are interested, you can also participate in the requirements gathering process. Thank you for your suggestions, which I have kept on record.

As you can see, there’s a lot of demand. Because are private take time to write, so the efficiency is relatively low. Today we will complete this little feature point: test report jump to the corresponding case.

Historical reasons

Before we do that, let’s take a look at the situation. Our use case has a unique ID, but for historical reasons it was originally designed to include a use case directory ID in the use case URL (this is a reference to yAPI).

The reason why people do this is to be able to find the corresponding directory directly in the URL, and their directory needs to support URL access. But we can’t do that today, for example:

No matter how we switch the directory on the left, the URL doesn’t change, but yAPI supports it, and when it switches directories, the corresponding URL will change.

Let’s look again at the URL of our use case:

At present, the data is determined according to the directory ID/use case ID, but because our test report only stores the use case ID, not the directory ID, we cannot jump to the specific use case page for the time being:

Now, this is embarrassing, because after thinking about it for a while, I was going to remove the directory ID from the URL, but THEN I realized that when I added a test case, which directory it belonged to, I recorded it in the URL, so it was embarrassing. Let’s not go there for the moment. Let’s think about it a little differently. When we get the test report data, we’ll look up the use case list.

Modify the report query method

Change the report query method, notice that the join query is used and the directory_id of TestCase is also checked. Since the join result of sqlalchemy is separate and not in a model object, let’s see what.all() returns.

What you can see is that it’s a meta-ancestor, which is something like this:

[(PityTestResult, directory_id)]
Copy the code

That’s why we need to iterate through and unpack it, but since TestResult doesn’t have the directory_id field in it, what can we do? So we also need to modify the model:

We add a directory_id field to the PityTestResult object, which will not affect the database as long as it is not a Column.

Finally, we can re-assign the retrieved directory_id to the object.

Take a look at the results:

You can see the directory_id already in there, indicating that the query is done, and then modify the front-end code.

Modify front-end code

Look at the results:

Today’s content is relatively brief, mainly because the blogger has taken out a lot of nucleic acid recently, next time fill up a little more. And I hope you’ll get involved in the pity discussion