Tips & Tricks – Improve Your E2E Tests With an API Testing Feature
Artem Golubev: Hello everyone. Hopefully, this session will be helpful. Today’s feature that I’d like to show is pretty straightforward. So we’ll take an opportunity to learn a little more about it. Okay. Employing API calls as part of an end-to-end test that includes UI stages will provide you with the greatest benefit when using testRigor. So this is where testRigor provides the most value. So, in general, testRigor is an end-to-end testing system. So let’s move forward with Amazon as an example, on Amazon let’s sign up to have a similar experience of your own.
So let’s create an Amazon test suit, you might be willing to set up a username password and generate a test; of course, you have it all right, so we have created a new Amazon test, now let’s make some simple tests.
And then we will extend it entirely arbitrarily. So, let’s enter this and type PS5. We click on the PS5 Console, choose this completely absurdly expensive option, and then click “add to cart.” Let’s stop there since you can see that we are executing the steps there, so let’s make it a little shorter.
So API, recording API, and second run. This is our test that’s kicking off. Okay, great. So this pure UI steps test is not even a test because it doesn’t have any validations, just a sequence of some steps in the UI. However, that is not what you’re looking for.In light of this, let’s look for any open APIs that you may use to play.. As you can see, I just Googled simple API online.We have this post API, right. This is one way to do it.
Another way to do it is you can go to Resources. And you can go to documentation. Remember that documentation is always your best friend. And you click on that, and you can search for API. And as you can see, you are API testing here on the left. So let’s go over, and as you can see here, we can do many different things. But most importantly I want to point out here today that our commands have examples. This is exceptionally important.
So our links to examples in testRigor will make it a little bit easier for you to see how it works. And a few contacts are not much better. This is highly realistic as well, possibly we can get. But there’s an example here that works, and you can steal that example.In order for us to do that, they also use some API. I copy and paste. The excellent advantage of these particular examples is that they works well for us, pointing you to a public test suit that contains this test is because these tests have executed and run, and you can copy and paste them until the run. So this is why we were doing that.You can research working with samples and Minder; there are more options available, so you can always go to Resources, sample tests.
And you get into fundamental issues with everyone who have consciously opted to open source everything on their public open-source accounts.. So you can look into all the different stuff that you’re doing.
Anyway, so now Amazon’s all good. It just took a little bit of time. Sort of a bunch of stuff. It’s just posting something on Amazon. You can also steal from those examples. All right. Let’s struggle a little bit, and let’s copy a sample from the documentation and then modify it a little bit. So let’s go ahead and copy this example. This is more or less static and doesn’t pass any dynamic parameters. Like this is our test and pasted in here. So now you don’t need a parameter as a star because we will be holding a static API. So you paste API here. However, you want to construct your URLs, which you call APIs that start with a home prefix.
Why is that? What is the home prefix in the first place? So home prefix is first a protocol and domain. So if you have a long URL like this HTTPS, amazon.com/smartcard, the home prefix would be this part. So it’s protocol and domain. Why do we even bother and extract this? This is because we want our customers to be able to reuse this test suite in different environments and different endpoints. For example, if you have created a test suite on a staging environment, and when you want to run on every commit on separate dynamically allocated Dev, Environments that appear every time you create a commit, you can do that. Just override your lending URL once if you use the home prefix. So this is why it is so vital in the documentation.
However, in this example, we will use this. We sometimes use this standard with accepting application JSON and then… I think it gets, and there is no [unintelligible] form.
However, let’s get the content of it. So this will get the full range; however, there’s another interesting trick, and again it is in the documentation called JSON path.
I will get into that in a second. But the point is you will be able to extract a specific part from the JSON path, and like in this case, let’s do it all right. So I think we have to pass out the documentation on JSON. So, as you can see, API testing is the JSON path. The link goes to the documentation path here, and it talks about the JSON path. The good thing about it, is this. You can test your JSON path for another place where you can place it, and you can paste your JSON path, and we will try to get this title. So time based. That is not what I was expecting.
This is much longer. I think it’s got that third one. So I assume it starts indexing at zero, so it wasn’t yet. And yet second, we have to use one okay. This is precisely what I need. Copy this. I’d say we want this second title to save it as the title. And then, they can do the validation. Check that stuff store value title itself is equal to. And this to ensure this test illustrates several things. We are representing several things here: number one, API call, number two, using JSON path and sending it as title, and number three within validation.
Moreover, its self-worth is essential. Because as soon as you’re not specifying itself, it uses that value to find something on the page. So the default behavior is working with your page or mobile screen. So if you didn’t specify itself, it would go ahead and find it on the screen and try to get its value. On the other hand, if you’re establishing yourself with meaning, don’t go anywhere. We need the importance of this title. That’s it. All right. So that’s some data in a test that takes too long because last time, okay—getting into our Console. Card. Great. Allow the calling API and validating historical. So another last thing I would like to show you is where you get the data? So how do you know whom this API returns on? So if you click
More Details versus the extra info button and see API call response, it’s always printed here. And whereas also stored value is to this one. So you always have the complete API response for all your API calls in case you’re in doubt. And you want to make sure you’re getting the correct API. You’re getting the proper responses, not errors and all this stuff. And, of course, it was stored values that were extracted. And, of course, the validation succeeded. Because as we have seen with Data, it is precisely what we need. Because once again, we looked into this JSON path documentation and opened up this place where you can place your JSON Path expression.
You can learn how to recognize it in the documentation right here. And construct your stuff and see how it works. If it doesn’t work, you’re missing something. It will give you an error message. So let’s try to break what is very stable. So here, as you can see, this one is hurt, and you’ll know that you’re interested in the JSON path expression is broken. So JSON path is like XPath for XML or HTML, but it has been built for JSON to extract the data for your transnationals. All right, and this is it—all for this presentation.
Please ask questions? What are the broad types of API that you can work with? Great question. Go back to API Documentation; go to API testing, as you can see here, so there are different types of HTTP API Calls. And there are examples for each one.
Connie Lund: Does anybody else have questions? Could you put them in the chat? All right, do you have anything else to add? Artem otherwise, we’ll wrap up, and in two weeks from now, in June, we’ll be having the next session.
Artem Golubev: No, I think this is it. I’ve invoked four main points. I think that should be enough for people to continue exploring. Good luck with your API testing, and do let us know if you have any questions. Or something didn’t work as you would expect.