GitLab Quality Department, 30 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Functional Testing of Large Merge Request

Description

Showing how functional testing of large merge request work and how to execute them.

A

Hello, my name is thomas launikic. I am the sat for code review and I've been working this last okr on the performance and functional testing of large merge requests in this video. I want to show you a little bit more about the functional testing of large merge requests, especially about how it is set up, how you can execute a test and, finally, how the setup can be expanded, as well as on what pipelines it is currently running.

A

So, let's begin first off, I would like to share my screen and show you what example project I've been using to actually facilitate the large merge request. So I have created a large project which is more or less the same project that we have on the performance side. The only difference is since this needs to be exported and added to our main gitlab project. It was a bit too large with a bit I mean it was like a gigabyte large, so to reduce the size.

A

I have stripped every single file that is not later changed in the merge request, which means that now the new exported file size, uh 200 kilowatts.

A

So if you look on the left side, you can see, there is one single merge request, called large merge, request, merge, request and it more or less copies everything that the functional merge request test uses. um I have to facilitate the com, the comment section.

A

I have just used dummy text but copy pasted it so that it has the same amount. The main difference here to the function to the performance test is, as in this case, the merge request is not merged, which means it can be used to be merged and test. This functionality as well and also all the threads are not resolved.

A

So this also adds another layer of testing to see if this also changes anything in the files changed. Every single file that is in this project is being changed. There is one single file that is added additionally to the normal 1875 files, and this one is the last file in this list. It which is the edit file and then a times the zero dot text.

A

um This peculiar file is added because a normal fabrication of a merge request in our functional tests normally adds this. This file. It contains like just a text which says file edit, and this makes it easier for us when we switch the context and say: okay, we want to test the large merge request to actually use this file still because it has the same content and we don't need to change any settings in the normal test procedure. We can use all tests as they are so now. I want to show what pipelines this is using.

A

Currently, this is only being tested in the master pipeline, which means every time you have a merge request. You can actually trigger the large merge request test. It is in the qa testing pipeline. You can see it here. It's in this case enterprise edition large setup and currently it executes one test. There is uh as we as I'm currently recording this another merge request that adds two more tests to it and, I will say, share, show how easy it is to actually add new tests later on in this video.

A

So, as you can see, this would be the setup itself, and now I want to show how to actually test this. We are now currently in the main uh gitlab project, specifically in the qa folder of the main gitlab project, and what I'm going to show you now is. This: is the command to actually execute the test?

A

In this case it executes against my instance, uh as you can see, if you ever have run the normal gitlab functional testing suite, you can see that this is more or less the same command that you would normally use.

A

uh Of course you can skip this initial part here, which is from uh from the bundle execute in qa and to the gitlab qhm.

A

Now the only difference here to, if you want to run every single test is that you add the tag can use large setup.

A

This is because.

A

Now open the file.

A

um I think it should be this one. Yes, uh you can see that the test itself only has this single tag here, which is added, and that already tells the suite everything it has. It needs that this test can be run using a large merge request.

A

The main difference and how it differentiates itself is that we here use the merge request fabricate via api uh command and the fabricate via api command normally is something that creates a test using the api by the merge request via the api by creating a project and then a merge request inside this project, all serially, while the test is running in this case. What we do here is we don't use this specific api situation, but what we do is we switch context. We say: okay, if the tag is executed is added in the execution.

A

We in that case, don't use the api, but we actually use the import project functionality of gitlab and we use the exported tar.gz file and we upload it to gitlab and then switch to the merge request. That is that I have shown you before. So, in that case, we can do the same thing which we would normally do. The only difference is that, instead of just creating a merge request with one single file, we have our big merger cost.

A

um The reason why we did that is because we don't want to repeat tests. We would have to recreate the same test by just using the large merge request. In this case, the only thing that actually is needed is just to add the tag and, in some cases, clean up the test. If the test is a bit unruly, I would say, or if it uses old methods, but this normally should be done anyway.

A

So, as you can see, this is more or less it.

A

If there are any questions about this, please feel free to reach out to me or to the quality channel, and we will all be happy to answer any questions you have. Thank you very much for watching and until next.

A