GitLab Quality Department, 7 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Contract Testing Base Setup Introduction

Description

Just a short introduction on how Contract testing is executed.

A

Hello, this is a short demonstration about how contract testing and its first stage is going to work. So let me share my screen.

A

um As you can see here, I have created a test project on my gdk. uh In this case, I don't even use a gdk. I just used a docker environment which I have link to gitlab.test. This is running on my local machine.

A

So, as I said, I have created a merge request, an underlying project, of course, and in the merge request, I have just added like one resolved issue, one resolved discussion with two comments and one code discussion which doesn't have anything additional and it's not resolved.

A

The merge request has all the basics, nothing major. So now, how do we test this? um There are two concepts here: first off the from the consumer side. If they want to have some things very specific inside the merge request, endpoint what they would do is they would go into the contracts folder- and this is all inside our main qa folder and the contracts folder consumer side.

A

Here they can specify different fixtures. I will show you one fixture. This is, for example, the metadata fixture, and here we are using matchers in that case, for example. Here this is important, even though this is a 1. We are expecting a string, not an integer, whereas in the size we are expecting, we are expecting an integer.

A

All of these are define later what the contract looks like, which you can see in this specific instance, one folder up inside contracts. Here you can see we have different json files as contracts. These are, as I have written in the description of the merge request. Only temporary later on. We will use a centralized data bank, which stores them much more nicely and is much better viewable.

A

Now, if we go back to the consumer.

A

We can now, if we have changed anything inside the fixtures or we created a new um contract inside the consumer project. We just and run npm test. This runs all our specs. In this case, we have three one is about the discussions. One is about the divs and one is about the metadata of the merger quest itself.

A

So what happens now is that we have the contracts.

A

Normally, you would have also now a task which pushes these contracts to the broker or, as I said, like a centralized data bank, but for now it is just stored inside the contracts folder, and if you do a push or a commit, it will normally add to contracts as well and push them to the repository.

A

So this is the consumer side for the front end. If we are now wanting to do a normal test, these are the tests that will be you uh executed the most. We are running uh the provider-based tests. Those are validating the contracts that are on the repository against the end points that we are using inside the product.

A

So, for the manual side, it is very useful when, for example, someone is writing something new or changing something on the back end, especially when it comes to end points, and they want to check if this is still valid against all the data that the front end wants. So what they would normally do is they would use our script, so we have a script which is located as all of the other normal execution qa scripts inside the bin folder of qa in this case contract.

A

So uh the script, a bit more detail is written in the description, so I won't go into what the script does, but what we want to do now is we execute it? So we of course use bundle to bundle it with all the packages that we need, the gems sorry um and we used our script and what first we want to provide is we want to provide the host in this case getlab.test and then, as we are testing dmrs?

A

If you don't provide the next step, the tests will skip because there are currently no other tests available. Of course, if you want, uh if new tests are available, for example, basic tested, don't need a specific, mr, they would run. Of course, in this case we only have a mr test, so we need to provide a specific link to nmr. So what we do is we just take dmr link.

A

And we run the test, so what is now happening? Is it's running all of our tests against um the underlying merge request, and it's checking, of course, for first, if it has the correct status in this case, it should be because those are public projects uh that it has a matching body and that the header provides the correct details we want.

A

So this is a short example of how these tests would be run. Of course, uh future uh improvements would be to have a more automatic approach with automatic provisioning and even pipeline related automation for the test to be run on every merge request. For example, thank you and that's. It.